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[57] ABSTRACT 

A method and apparatus for converting a set of functions of 
any software system that does modeling into a correspond- 
ing set of parametric functions that, when called, generate 
not only a resulting model, but also a dependency graph 
representation of the model. Hie dependency graph can 
include directed functions and non-directed constraint 
relationships, and is used when a change is made to the 
model so that only affected portions of the model are 
reevaluated. The dependency graph can be visually pre- 
sented to a user, and can be created or edited through a visual 
programming environment The graph can be modified to 
change either input values to the model, or the graph 
elements that represent the functions used in creating die 
model When changes to the dependency graph are made, it 
can be reevaluated to incorporate the changes into the 
model. When the visual programming environment is used 
to modify the graph, the environment calls the parametric set 
of functions. The set of parametric functions is generated by 
creating wrappers in a standard programming language 
around the functions of the software system. The depen- 
dency graph can also be used to generate a computer 
program in a standard language that, when executed on the 
software system, regenerates the model as well as the 
dependency representation. The computer program can also 
be edited and then executed on the software system to 
generate a modified version of the model. 

30 Claims, 32 Drawing Sheets 
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METHOD AND APPARATUS FOR modifications, they have several disadvantages. The history 

REPRESENTING DATA DEPENDENCIES IN module created by these systems reflects the sequence in 

SOFTWARE MODELING SYSTEMS which the commands were received during the interactive 

^ ^ design session, and does not represent the structural depen- 

FIELD OF THE INVENTION 5 dency of the resulting design. Thus, when any modification 

This invention relates to a method and apparatus for is to ^ d* 8 ^. no how small > toe entire 

representing data dependencies in software modeling sys- module must be re-executed to generate a new design, which 

terns, can delay the design process. 

Some CAD systems have been developed that include 
BACKGROUND OF THE INVENTION 10 parametric capabilities so that when changes are made to a 

Software systems exist in many different fields in which ^siffi parameter, the system modifies the design by updat- 
a user interacts with the system by entering a series of mg only ^ P°^ oas mat affected by the modi- 
commands during an interactive session, and in response, fied P aramete *'- However, these parametric capabilities are 
the software system executes a number of functions that take conventionally incorporated into the proprietary commands 
actions defined by the user commands. Computer aided 13 used by foe system Therefore, if a third party vendor desires 
design (CAD) systems which generate a computer model of to P* 0 ^ add " on capabilities to the software system, the 
a design during an interactive design session are one new ^abilities must be integrated into the proprietary 
example of such systems. CAD systems, such as the command set of the system if the parametric capabilities of 
CADDS line available from Computervision Corp. of me ^ stem ^ t0 1x5 ™intained. 

Bedford, Mass., provide tools fox generating computer mod- Another disadvantage suffered by the above-described 

els of mechanical devices in two and/or three dimensions. command based systems, whether or not they include para- 

TVpically, a user interactively builds a model by entering, metric capabilities, is that modifications to the history mod- 

into a user interface, a series of system-defined commands ule must De made usm fi me proprietary commands. Thus, the 

to generate a product design. For example, a user may input user must l earn a new 'frograrnming language" in order to 

a command such as insert box, along with desired dimen- 25 modir V we design reflected in the history module. In 

sions flength, height and width) and a desired location for addition, history modules of this type are difficult for a 

the box, to add a box with the specified characteristics to the designer to work with because they do not represent the 

design. Other commands can add elements such as structural dependency of the design, but rather, relate only to 

cylinders, spheres, bores, etc., which can be integrated with me sequential manner in which the commands were received 

the box to complete the product design. Thus, by inputting 30 during the design process, 

such system-defined commands, the user can build a com- SUMMARY OF THE INVENTION 
puter model of a mechanical device. 

The user interface in a CAD system conventionally ^ accordance with one illustrative embodiment of the 
includes a command processor that processes commands « mveilti0D > a method and apparatus is provided for convert- 
received from the user. The command processor generally in S a set of functions for any software system that does 
can generate a command file that stores the received com- modeling into a corresponding set of functions having 
mands to generate a record of the interactive session Parametric capabilities. Thus, parametric capabilities can be 
between the user and the CAD system. Since the commands provided to a software system whose set of functions have 
and command processor arc generally proprietary to the ^ no Cerent parametric capabilities, 
particular CAD system, the command file is by nature a 1° another illustrative embodiment, when the parametric 
proprietary language. On receiving a command, the user functions created by the present invention are called during 
interface rails an application programming interface (API), 311 interactive user session or by a program to create a design 
which is a software function that causes the system to 01 model, the parametric functions generate not only the 
perform some activity. For example, in a CAD system, an 45 resulting model, but also a dependency graph representation 
AH causes a geometric modeler to generate and intercon- °f me model. 

nect entities, such as edges, faces, and vertices to achieve the In a further illustrative embodiment, the dependency 

design action required by the proprietary command, and graph created by the present invention is created and evalu- 

stores the entities in a database. The combination of the ated in such a way mat directed functions and non-directed 

entities created by a series of commands received from the 50 constraint relationships can be mtermingled in a single 

user during an interactive session defines the product design. dependency graph. 

If the user desires to change the product design by In a still further illustrative embodiment, the dependency 

changing a parameter of one of the previously created representation created by the present invention is used when 

entities (e.g., the height of a box), the user can modify the a change is made to the model, so that only portions of the 

history module to reflect the change, and then provide the 55 model affected by the change are reevaluated in creating the 

history module as the source of commands to the system updated model. 

which re-executes all the commands in the history module. In accordance with another illustrative embodiment of the 

When the commands are re-executed, they are provided to invention, the dependency graph can be visually presented 

the command processor, which again calls the appropriate to a user to represent the dependencies of the model. 

APIs, which in turn typically discard the old design entities so In accordance with another illustrative embodiment of the 

and create new entities to effect the new product design, as invention, functions executed on the software system can be 

well as a new history module. This type of system is referred grouped into hierarchical groups in the dependency graph, 

to as a "command based* 1 system since the command is the Thus, design goals of the user involving multiple functions 

basic building block. can be represented with a single hierarchical entry in the 

Although the above-described command based systems 65 dependency graph, 

allow a user to record an interactive session, to modify a According to another illustrative embodiment of the 

record thereof, and to re-execute based on those invention, the dependency graph can be created or edited 
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through a visual programming environment. When changes FIGS, la-lb are flowcharts representing the steps per- 

to the dependency graph are made, the graph can be reeyalu- formed by the operator evaluator for an associative API of 

ated to incorporate the corresponding changes into the the present invention when it is called to evaluate an 

model. operator in the dependency graph; 

In another illustrative embodiment, the dependency graph 5 FIG. 8 is a flowchart of one implementation of the 

created by the present invention can be modified by the user evaluation symbolic pass of the evaluation method of FIGS, 

to change either input values to the model, or the graph la-lb; 

elements that represent the functions used in creating the yiQ t 9 i s a flowchart of the directed operator processing 

model, routine of the present invention; 

In a further illustrative embodiment, when the visual 10 HGS io a -106 are flowcharts illustrating the non- 
programming environment is used to modify the depen- directed operator processing routine of the present inven- 
dency graph, the environment calls the parametric set of 

functions created by the present invention. The parametric fjq # u is a flowcnart mustrating the evaluation pass of 

functions are compatible with visual programming tech- ^ evaluation method rf BGS . la _ lb; 

tuques that allow a user to graphically generate and edit the 10 m „ M . , 

dependency graph. HG * 12 1S a flowchart representing the steps of an 

z. r /, .,f ^ ^ ... t - * integration process of the present invention that integrates 

In a further illustrative embodiment, the set of parametric . ^ * ^ . , r fl , ^ 

, ' . * • . ... \ u f . the present invention into a software system; 

functions created in accordance with the present invention r J 

are generated by creating wrappers around the functions of ™S- flowcharts representing the steps of the 

the software system. The wrappers are written in a standard 20 program generation method and supporting routines of the 

computer programming language so as to be compatible present invention; and 

with non-proprietary tools, such as the visual programming FIG. 14 is a block diagram of a hardware system on which 

environment discussed above. the present invention can be operated; 

According to a further illustrative embodiment of the 2$ FIG. 15 illustrates a box having a countersunk hole 

invention, a method and apparatus is provided for generating provided therein; 

a computer program from a representation of a model or pjQ. 16 is an illustrative dependency graph of the present 

design on a software system, the representation defining the invention without the use of a hierarchical operator; 

model in terms of the dependency relationships amongst a mQ 17 {s a rf me dependency graph of 

plurality of model entities that form the model. The com- 3Q mG u usk a foerarchical operator; 

outer program can be written in a standard programming ^ , .„ ^ - 4 ^ 

language. When the program is executed on the software ™- u 18 15 a lUustration of me irmolementetion 

systemT it generates the model as well as the dependency £ * e ^archical operator in the dependency graphs of 

representation. Thus, the computer program can convert a rlub. 16-17, 

modeling session into a standard language program for FIGS. 19a-19d are flowcharts of a method operated upon 

efficient storage. The computer program can be generated eacn operator committed to the dependency graph of the 

from a dependency graph created in accordance with the present invention; 

present invention. FIG. 20 is a flowchart illu strating the interpreter routine of 

In another illustrative embodiment, the computer program the present invention ; 

can be edited, and then executed on the software system to ^ FIG. 21 is a flowchart illustrating a method for processing 

generate a modified version of the design. edits a design and dependency graph of the present invention 

BRIEF DESCRIPTION OF THE DRAWINGS usin S a prograniming environment; 

Other features and advantages will become apparent from . ™ ^ * ^chart illustrating the steps of a redefine 

the following detailed description and from medra wings, in in P ut routme of we P rcseilt ™™***> 

wxiich* 45 FIG. 23 is a flowchart illustrating the steps of a replace 

FIG. 1 is a high level flowchart representing the steps of operator routine of the present invention; 

a method in accordance with the present invention; FIGS. 2Aa-2Ab illustrate an exemplary visual represen- 

FIG. 2 is an illustrative dependency graph created in t^ 00 of a dependency graph according to the present 

accordance with the present invention; 5Q invention; and 

FIG. 3 is a graphical representation of a user's perspective FIG. 25 is a high level flowchart representing the steps of 

of a CAD system that employs the present invention; a method in accordance with the present invention. 

HG. 4 is a graphical representation of the relationship 

between the associative API builder tool of the present DETAILED DE^uuruuN 

invention, the associative APIs that it creates, and the 55 x. Overview 

proprietary APIs of a software system on which the asso- accordance with the present invention, a method and 

dative subsystem of the present invention is installed; apparatus is provided for converting the APIs in a modeling 

FIG. 5 is a graphical representation of the manner in system into associative APIs that, when called from a user 

which commands received at the user interface of a CAD interface or as part of a larger program during a modeling 

system using the present invention call an associative API 60 session, generate a graph representing the dependencies 

and the associative API processor to construct dependency between the API functions called during the modeling 

graph entities to represent the command, and to evaluate session, me arguments to me APIs, and the results of the API 

those entities to perform the design action requested by the functions. From the dependency graph, the present invention 

user; allows a user to: (1) change inputs to the graph andhave only 

FIG. 6 is a flowchart representing the steps performed by 65 the affected functions be re-executed; (2) generate a non- 

the associative API processor of the present invention when proprietary computer program that represents the structural 

it is called by an associative API; dependency of the graph, and that when executed, produces 
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the same result as the modeling session that created the 
graph; (3) view the graph to visualize the dependencies; (4) 
edit the graph to alter the dependency structure of the model; 
and (5) edit the graph to change the API functions used to 
generate the model. 

In accordance with one aspect of the present invention, a 
method and apparatus is provided for generating, based on 
an execution of software system functions that produces a 
design, a dependency graph representation of the design, and 
a non-proprietary computer program that is generated from 
the dependency graph and also represents the structural 
dependency of the design. The method is illustrated in the 
flowchart of FIG. 1. In step 001, the design is generated by 
the execution cf a group of functions in the software system 
during a design session, and a dependency graph represen- 
tation of the design is generated in step 203. If the design is 
modified during the design session, the present invention 
uses the dependency graph to determine which portions of 
the design will be affected by the modification, and 
re-executes only so much code as is necessary to change the 
affected portions of the design. As shown in step 205, after 
completion of the design session, the dependency graph can 
also be used to generate a computer program in a standard 
language that, when executed, will generate the dependency 
graph and the design that it represents. The user can, as 
shown in step 207, edit the computer program to represent 
a modified design, and run the computer program on the 
software system (step 209) to produce the modified design. 
Because the computer program is in a non-proprietary 
language, the designer need not learn a proprietary language 
to modify it Furthermore, since the program is developed 
from the dependency graph, rather than from the sequence 
in which commands were received from the user during the 
design session, the computer program represents the struc- 
tural dependency of the design. Thus, the organization of the 
program is easily understood by the user, allowing for easy 
modification of the program, even if the user does not have 
significant computer programming experience. 

As stated above, software systems conventionally include 
application programing interfaces (APIs), which are high 
level functions that generally map in a one-to-one relation- 
ship with system-defined user commands. In accordance 
with the present invention, a tool is provided which, as part 
of an integration process for integrating the present inven- 
tion into a software system, initially is run over each API in 
the software system to generate a new set of APIs. The user 
interface for the software system is then modified to call 
these new APIs in response to commands received from the 
user. The new APIs created by the tool of the present 
invention do essentially two things. First, the new APIs 
perform essentially all of the functions performed by the set 
of APIs provided by the software system. Second, the new 
APIs also create and maintain a dependency graph repre- 
sentation of the design generated by the user, which can be 
used to provide the parametric capabilities discussed above, 
to allow for graphical editing of the design through edits to 
the graph, and which can also be used to generate the 
standard language computer program that represents the 
structural dependency of the design. In this manner, the tool 
of the present invention forms an associativity subsystem 
that can be initially run over any software system that is 
composed of high level functions or APIs to convert the 
system, in a manner transparent to (he user, into one that has 
the above-described associative capabilities provided by the 
present invention. 

As should be appreciated from the foregoing, and as will 
become clearer in the description below, the present inven- 
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tion can provide parametric capability to any software 
system composed of APIs, even if that system does not 
include such a capability in its command set This feature of 
the present invention is advantageous in allowing third 
5 parties to provide add-on capabilities to a software system. 
To provide additional capabilities to the software system, a 
third party need only provide commands and corresponding 
APIs that are compatible with those of the system. The 
additional commands need not be integrated into the com- 

10 mand set of the software system to provide parametric 
capabilities, because when the tool of the present invention 
is run over the software system having the third party's 
commands and APIs installed, parametric capabilities are 
provided in the new APIs generated by the tool of the present 

is invention, and in the manner in which these new APIs are 
used to generate, maintain and update the dependency graph 
representation of the design created during a design session. 

In the description below, the illustrative example provided 
for the software system on which the present invention is 

20 operated is a CAD system which receives commands from 
a designer during an interactive design session to create a 
product design. However, it should be understood that the 
present invention is not limited to use with CAD systems, or 
with systems that receive inputs during an interactive ses- 

25 sion. The present invention can be used with any software 
system mat is composed of functions, and that receives 
inputs from a user in any number cf ways. For example, the 
present invention can be used with a software system for 
creating economic models based on a number of parameters, 

30 or many other types of software systems. Thus, although the 
terms "model" and "design" are used to refer to the software 
system output that is modeled by the dependency graph, 
these terms are not intended to be limited to CAD models, 
and are intended to encompass the output produced by any 

35 software system based on the execution of a number of 
functions. 

FIG. 2 is an example of a simple dependency graph 1 
generated in accordance with the present invention operating 
on a CAD system. The graph 1 is generated during an 

40 interactive design session wherein a designer enters com- 
mands to insert a box into the design and to calculate the 
weight of the box. Along with the command to insert the 
box, the designer provides arguments which establish the 
length, width and height of the box, as well as the coordi- 

45 nates for the center of the box. These arguments are respec- 
tively represented in the graph 1 as data objects 3-6. Data 
objects are components in the graph that contain values. 
Each of the data objects 3-6 is connected to an operator 7 
that indicates the function with which it is associated, i.e., 

50 insert box. Operators are components in the graph that take 
action on at least one data object and are functions or 
evaluable expressions that represent the design actions taken 
by the user. The data objects 3-6 are respectively coupled to 
the operator 7 via relations 9-12, Relations are components 

55 in the graph that identify what role each data object plays 
with respect to an associated operator. In the example shown 
in FIG. 2, the relations 9-12 respectively identify their 
associated data objects as establishing the length, width, 
height and center of the box. The result of operator 7 taking 

60 action on data objects 3—6 is represented in the graph by 
relation 15 and data object 17. Data object 17 represents the 
software entity created by operator 7, and relation 15 iden- 
tifies the result of the operator as a box. 
The command to calculate the weight of the box is 

65 represented in the graph by operator 19. A box is one of 
many structures that is more broadly classified as a solid. To 
calculate the weight of a solid, the operator 19 multiplies the 
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volume of the solid, received via a first relation 21, by the translates expressions received from the visual program- 
density of the solid received via a second relation 23. In this ming environment 50 into corresponding associative APIs 
example, the solid was already specified in the design, rather that implement the desired design actions to modify the 
than being provided as an argument with the calculate design. 

weight command. This dependency relationship is repre- 5 IL Integration of Associativity Subsystem 

sented in the graph by the relation 21 being connected to the As discussed above, to enable the present invention to be 

data object 17 that represents the box. Since the density was used with any of a variety of software systems in a manner 

not previously specified in the design, it is provided by the that is transparent to the users of those systems, a software 

user as an argument with the command to calculate the tool is provided that is executed once on each software 

weight of the box. This lack of dependency is represented in 10 system to provide it with the capabilities of the present 

the graph by the relation 23 being connected to a data object invention. This software tool can be written in any standard 

25 that represents the density argument and is not output computer language, and is preferably written in an object- 

from any operator in the graph. The result of operator 19 oriented programming language such as C++. FIG. 4 illus- 

taking action on data objects 17 and 25 is represented in the trates the architecture of this tool, which is referred to as the 

graph by relation 27 and data object 29. Data object 29 15 associative API builder tool 61. The tool 61 is executed once 

represents the software entity created by operator 19, and in connection with each application prograrnming interface 

relation 27 identifies the result of the operator as being the (API) in a software system which is to incorporate the 

weight of the box. features of the present invention, and generates a corre- 

As seen from the simple example shown in FIG. 2, the sponding associated application programrning interface 

dependency graph created in accordance with the present 20 (AAPI) for each. In one embodiment of the invention, the 

invention illustrates the structural dependency of the design builder tool 61 operates upon each API for the software 

created during an interactive session. The graph illustrates system individually. 

that the weight 29 of the box is dependent upon the density As discussed above, an API is essentially a high level 

data object 25, as well as data objects 3-5 representing the software function in a system that typically corresponds to 

dimensions of the box. Similarly, the graph illustrates that 25 a command mat can be received from a user. In the example 

the data object 17 representing the box is not dependent on of FIG. 2, the CAD system would have APIs that implement 

the density data object 25. Therefore, if the designer chose the functions of inserting the box and calculating the weight 

to modify the density of the box during the interactive of a solid. Conceptually, the associative API generated by 

session, the only portion of the graph that would need to be the builder tool 61 for each API performs two roles. First, it 

re-evaluated to update the design would be operator 19; 30 performs the same role that its corresponding API performs 

operator 7 would not need to be re-evaluated. Thus, when a in connection with generating the product design for the 

design modification is made, the dependency graph enables software system. For example, an associative API generated 

the present invention to re-evaluate only operators that are for the API in the FIG. 2 example to insert a box will 

dependent on a modified data object. Although the illus- perform the function of inserting the box into the product 

trated example is quite simple, it should be appreciated that 35 design and displaying it on the CAD system. Second, each 

the computational time savings provided by this feature of associative API also performs the role of representing in the 

the present invention can be significant, especially for large dependency graph the action taken by its corresponding API, 

designs, so that the portions of the design generated by the API 

A graphical representation of the user's perspective of a understand how they are associated with other aspects of the 

CAD system on which the associativity subsystem of the 40 product design. 

present invention has been installed is shown in FIG. 3. The Because each associative API performs two roles, the 
CAD system 35 includes a user interface 37 that receives builder tool 61 can simply generate two functions for each 
inputs from the user as conventional CAD commands 39. API, i.e., one function to perform each role. However, in a 
Topically, a user will conduct an interactive design session preferred embodiment of the present invention, the builder 
with the CAD system by inputting a series of CAD com- 45 tool 61 generates a macro call that resolves to a call to a 
mantis 39. In response to the series of CAD commands, the generic function, referred to as the associative API 
user interface 37 calls corresponding associative APIs 42, processor, for generating the graph structure of each asso- 
which in turn call corresponding proprietary APIs 43 of the dative API, and one software function for each associative 
CAD system The APIs 43 are executed to produce a product API that performs the role of implementing the design action 
design 45. During the interactive design session, the as so- 50 in the product design. The arguments provided to the asso- 
ciative APIs 43 and a graph controller 47 together generate dative API processor are the name of the assodative API 
a dependency graph, such as the one illustrated in FIG. 2, calling it, and the arguments to that associative API. The 
that represents the structural dependency of the product builder tool 61 also produces a software entity (described 
design 45. At the end of the design session, the CAD system below) for each associative API that describes the topology 
can also generate, from the dependency graph, a computer 55 of the graph entities to be constructed for that assodative 
program 49 in a non-proprietary language such as C++ that, API, and the function represented by the operator created in 
when executed, will also represent the structural dependency the graph to represent the design action taken by the asso- 
of the product design 45. The user can then, using an ciative APL 

e<htc>r/c»inpUer/h^ As shown graphically in FIG. 4, the builder tool 61 

puter program 49 to represent a modified product design, 60 operates on function templates of the proprietary APIs 62 in 

and compile and link the program to the CAD system to the software system, and function templates for carrespond- 

generate a modified product design 45. Alternatively, the ing assodative APIs 66 to generate an associative API 63 for 

user can use a visual prograrnming environment 50 to each APL The function template for each API and assotia- 

graphically edit the dependency graph, which can then be five API defines the name of the function, the data type of 

used to generate a modified product design 45 and a modi- 65 its arguments and result, and the names of its arguments and 

tied computer program 49. The output of the visual pro- result Each associative API created by the builder tool 
gramming environment is provided to an interpreter 52 that indudes three components, i.e., an associative API macro 
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call 65, an associative API data component 67, and an 
associative API operator evaluator 69. As discussed more 
fully below, when tbe builder tool 61 is executed on the APIs 
of a new software system to generate an associative API for 
each, the user interface of the system is also modified so that 
each user command calls its corresponding associative API, 
rather than calling its corresponding API directly. In this 
manner, wrappers are provided around each of the APIs in 
the software system so that the added capabilities of the 
present invention are provided in a manner that is transpar- 
ent to the user. 

When called by a user command during an interactive 
design session, each associative API in turn calls the asso- 
ciative API processor 71 (FIG. 5). The processor 71 first 
updates the dependency graph to include an operator that 
represents the design action taken by the command, and then 
ensures that the function that actually takes the design action 
on the product design is called. Because the role played by 
each of the components of the associative APIs 63 is closely 
tied with the role of the associative API processor 71, these 
aspects of the present invention are described together, 
making reference to FIG. 5. FIG. 5 graphically illustrates the 
relationship of the AAPI components 63 to the associative 
API processor 71 and the CAD user interface 37. 

Each associative API that calls the processor 71 is repre- 
sented in the dependency graph by an operator having a 
specified number of data objects and a corresponding num- 
ber of relations that each defines the relationship of one of 
the data objects to the operator. The associative API pro- 
cessor creates a software entity to represent each operator, 
relation and data object in the dependency graph. In this 
context, the term software entity is intended to indicate 
entities created by a software program which may be an 
object in an object-oriented programming language such as 
C++, or for example a structure in a programming language 
such as C. The associative API processor 71 is generic in that 
it handles calls from every associative API in the same 
manner, without regard to the particular design action per- 
formed by the AAPL For example, making reference to the 
illustrative dependency graph shown in FIG. 2, the associa- 
tive API processor 71 treats the operators 7 and 19 that 
respectively represent insertion of the box and calculation of 
its weight in the same manner, simply connecting them up 
in the dependency graph to their respective data objects and 
relations. 

As mentioned above, in addition to executing the builder 
tool 61 on each API in the software system to generate an 
associative API for each, the integration process of the 
present invention also modifies the user interface 37 of the 
system so that in response to each command received from 
the user, the interface 37 calls a corresponding associative 
API, rather than calling an API directly. Specifically, it is the 
macro call component 65 of each associative API 63 that is 
called by the user interface. The user interface passes the 
associative API any data arguments included in the received 
command For the illustrative example shown in FIG. 2, 
when the user inputs the command to insert the box, the user 
interface calls an associative API corresponding to that 
command and passes it the data arguments received in the 
command relating to the length, width, height and center 
position of the box. When the macro call 65 of an associative 
API is called by the user interface, it in turn calls the 
associative API processor 71 (FIG. 5) and passes to the 
processor a string of data that contains an ordered list of the 
arguments received with the command that called the macro 
65, as well as the name of the macro which is used to identify 
its. function (e.g., insert box, calculate weight). 
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Because the associative API processor 71 is a generic 
dependency graph builder and is not specifically designed to 
handle any particular associative API, the string that 
includes the name of the calling macro and the list of ordered 
5 data is insufficient to specify the manner in which the 
dependency graph is to be updated based upon the calling 
macro. Thus, the processor 71 uses the macro name in the 
calling string to receive additional information about the 
calling AAPI 63 from its data component 67. The data 
10 component 67 of each associative API includes textual 
information that defines the number of input data objects for 
its corresponding API, their respective relations to the 
operator, and the relation of the result data object Whenever 
the software system is started-up, and before initiation of a 
15 design session, the associative API processor 71 parses an 
ASCII data file that describes each associative API 63 
(provided by its data component 65) to generate a hash table 
73 that includes an entry for each AAPI, hashed by the AAPI 
name. When called by an AAPI during an interactive design 
20 session, the processor 71 uses the corresponding entry in the 
hash table 73 to create the operator, relations and data 
objects that represent the calling AAPI in the dependency 
graph. The hash table entry for each associative API is in the 
form of a software entity, and identifies the number of input 
25 data objects for the AAPI, the relation of each to the AAPI 1 s 
operator, and the relation of the AAPI output data object 
HI. Dependency Graph Creation 

When the associative API processor 71 is called by a 
macro call 65 during a design session, the processor 71 uses 
30 the name of the calling macro to index into the hash table 73, 
which outputs the software entity that includes the informa- 
tion relating to the structural characteristics of the calling 
AAPI. For example, for a call from the AAPI that relates to 
the function for inserting a box as described in connection 
35 with FIG. 2, the corresponding software entity output from 
the hash table 73 would include information indicating that 
the first argument in the ordered list of data passed to the 
processor 71 along with the macro name is the length of the 
box, the second argument is the width, the third is the height, 
40 and the fourth is the center position of the box. The asso- 
ciative API processor 71 includes a function that queries the 
software entity output from the hash table 73 to determine 
the manner in which the dependency graph should be 
updated for the particular AAPI macro that called the 
45 processor. This function asks the software entity output from 
the hash table how many inputs are associated with the 
calling AAPL Next, the associative API processor 71 asks 
the entity what name is associated with the first argument in 
the list of ordered data, and uses the name (e.g., length, 
50 width, height) to define the relation of the data object to the 
operator. The associative API processor 71 continues in this 
manner until the relations of all of the input and output data 
objects are defined. Ihe processor 71 derives the name of the 
operator from the name of the calling macro, which is 
55 included in the string of information passed to the processor 
71. 

As stated above, the associative API processor creates 
software graph entities to represent each of the operators, 
relations and data objects in the dependency graph. The 

60 graph entity created for each operator (e.g., insert box and 
calculate weight in the FIG. 2 example) includes a list of 
pointers to the graph entities that represent its relations. Each 
pointer includes the address of a memory location that stores 
a graph entity representing one of the relations. The graph 

65 entity created for each relation includes the name of the 
relation, and a pointer that includes the address of the 
memory location that stores the graph entity that represents 
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the data object connected to the relation in the graph. Finally, will be called to take the specified design action on the 

each graph entity that represents a data object in the depen- product design. The operator evaluator 69 for each AAPI 

dency graph includes a pointer to a memory location includes not only the name of the corresponding proprietary 

wherein the argument value corresponding to the data object API to be called, but also the names and order of the 

is stored. 5 arguments to be provided to the APL For example, when 

It should be appreciated from the foregoing that the evaluating the operator 7 shown in FIG. 2, the corresponding 

provision in the hash table of a software entity for each AAFT evaluator 69 would first request the operator 7 to 

AAPI that it can be queried by the associative API processor provide it with the argument representing the length of the 

71 to determine the structural relationship of the operator, box. The graph entity representing the operator 7 would 

relations and data objects related to the AAPI enables the 10 execute a function requesting each of its relations to identify 

creation of the dependency graph to be accomplished by itself. Once the length relation is identified, the graph entity 

only a single additional function (i.e., the processor 71) representing the operator 7 would request the graph entity 

added to the software system, rather than requiring that a representing the Length relation 9 to provide it with the 

separate graph manipulation function be generated for each argument defining the box length. The graph entity repre- 

AH in the system. is senting the length relation 9 would then request the graph 

IV. Overview of Dependency Graph Bvaluation entity representing the data object 3 to pass its argument, and 

In addition to updating the dependency graph in response once the argument is received, would in turn pass the 
to an associative AH macro call, the associative API pro- argument to the graph entity representing the insert box 
cessor also triggers the evaluation of each newly created operator 7, which would return it to the operator evaluator 
operator to take the design action on the product design 20 69. The evaluator 69 would request and receive me remain- 
specified by the calling associative APL The software entity ing arguments in the same manner. Once all the arguments 
that represents each operator in the dependency graph were collected, the operator evaluator would call the pro- 
includes two pointers relating to the operator evaluator 69 prietary API "C^__JNSEKr_BOX", with the call itself 
(FIG. 5) of the AAPI whose macro call resulted in the specifying the order of the arguments, to take the appropriate 
creation of the operator. The first pointer points to a library 25 action on the product design. 

wherein the operator evaluator 69 is stored, and the second When a proprietary API is called, it performs a design 

pointer specifies the name of the function in the library that action on the arguments passed to it, and in addition, passes 

is the operator evaluator. Thus, after the associative API the result back to the operator evaluator, which in turn passes 

processor 71 updates the dependency graph in response to a the result to the graph entity representing the operator being 

call from an AAPI, the processor 71 calls the newly created 30 evaluated. The graph entity representing the evaluated 

operator to evaluate itself. This process is illustrated graphi- operator then passes the result to the graph entity represent- 

cally in FIG. 5, wherein the associative API processor 71 is ing the output relation of the operator, which in turn passes 

shown calling the calculate weight operator 19 of FIG. 2 to it to the graph entity representing its data object, which 

evaluate itself. finally stores the result in a memory location pointed to by 

As discussed above, each AAPI created by the builder tool 35 the data object. In this manner, the result of the evaluated 

61 (FIG. 4) is a wrapper around a proprietary API in the operator, which may serve as an argument to other operators, 

software system. The operator evaluator 69 for each AAPI is is inserted into the dependency graph, 

a function that calls the name of the proprietary AH around 1 . Expanded Command Format Flexibility 

which it is wrapped. When called, the operator evaluator 69 In one embodiment of the invention, one or more operator 

collects the arguments from the input data objects connected 40 cvaluators 69 (FIGS. 4 and 5) are provided with a capability 

to the evaluated operator in the dependency graph, formats that increases the software system's flexibility in terms of 

the arguments in the form expected by the proprietary API, the manner in which certain design actions can be defined at 

and calls the API with the arguments in the correct order to the user level. For example, although the example described 

perform the desired design function. Referring again to HG. above illustrates a box as being defined by its length, width, 

2, the proprietary API in the CAD system for inserting a box 45 height and the coordinate position of the center of the box, 

may, for example, be named "CV_JNSEKT_JOX (1, w, h, it should be understood that there are other ways in which a 

center)", expecting that data arguments passed to it be user may want to define a box, such as by defining only the 

ordered as length, width, height and center. If a user input the positions of the box corners. This may be desired far certain 

command to insert a box with arguments specifying the design environments where the approach taken by the 

length as two, width as three, height as four and center 50 designer is more conducive to defining a box in this manner, 

coordinates as (zero, zero), the user interface would call the rather than by specific length, width and height. 

AAPI wrapped around the CV_JNSEKT_30X API, lead- Conventionally, if the CAD system does not include a 

ing to the creation of data objects 3-5 and 17, relations 9-12 proprietary AFT in which a box is defined by its comers, the 

and 15, and operator 7 in the dependency graph. When the user is not provided with a command to define a box in this 

AAH processor 71 instructs the operator 7 to evaluate itself, 55 manner. However, the operator evaluator function of the 

the operator evaluator 69 (HG. 5) of the associative AH present invention provides a wrapper around the proprietary 

would collect and order the arguments stored in data objects APIs that can provide increased flexibility in the format of 

3-5 and call the proprietary API as "CVJNSERTJOX the commands available to the user. For example, if a CAD 

(2, 3, 4, 0, 0)". This call is identical to one that would have system on which the tool of the present invention is run only 

been made directly by the user interface 37 in the software 60 provides for the creation of a box that is defined in terms of 

system if the software tools of the present invention had not its length, width, height and center, the operator evaluator 

been installed on the system to create a wrapper around the function of the present invention can enable the user to 

proprietary APL define a box in additional ways, such as by its corners. 

When the processor 71 calls a graph operator to evaluate In a preferred embodiment of the present invention, the 
itself, it is a straightforward process for the corresponding 65 dependency graph and the computer program generated 
operator evaluator 69 (HG. 5) to collect and organize the merefromrepresent me structural dependency of the product 
arguments in the order required by the proprietary API that design in a manner that most closely correlates to the design 
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atiions taken by the user during the design session. graph of FIG. 2, the calculate weight operator 19 calculates 
Therefore, when the feature of the present invention that the weight of a solid by multiplying its volume by a density, 
provides additional command formats is used, the depen- The specific solid being operated upon in FIG. 2 is a box, 
dency graph is preferably created and stored in the manner which is one of a broader class of solids, which could 
specified by the user. For example, if the capability is 5 include cylinders, spheres, etc. When defining various types 
provided for the user to define a box by its corners and the of application entities in an object-oriented programming 
user exploits this capability, the dependency graph operator language, a hierarchical structure can be used. For example, 
that represents the design action of inserting the box will functions and characteristics that are common to all the 
include data objects and relations that define the box by its specific types of application entities that belong the class 
corners. When the operator is called to evaluate itself and in 10 solids (e.g., a function to provide the weight of the solid by 
turn calls its AAFI operator evaluator 69 (FIG. 5), the multiplying its volume by its density) may be defined once 
evaluate* converts the representation of the operator in the in the definition of the solid class. The definition of each of 
dependency graph into the form required for calling the the more specific application entities (e.g., box, cylinder, 
proprietary API of the software system. Using the example sphere, etc.) within the class will include a reference to the 
for inserting the box described above, the operator evaluator 15 solid class and will inherit therefrom. Thus, the functions 
associated with the insert box operator would collect the and characteristics provided in the definition of the solid 
arguments defining the corners of the box in trie manner class form part of the definition of each of the application 
described above, and would process those arguments to entities that inherit from it, and need not be duplicated in the 
generate length, width, height and center coordinate argu- definition of each of the more specific classes of application 
ments to be passed to the proprietary insert box command, 20 entities. For example, each application entity in the box class 
which operates only upon arguments arranged and ordered has the capability of determining its weight, without a 
in that fashion. The increased flexibility provided to the user specific function to make this determination for the box, 
does not require the creation of new proprietary APIs, because that function is defined in the definition of a solid, 
because the flexibility is implemented by the wrappers from which the box class inherits, 
provided by the present invention around the proprietary 25 Using the inheritance capability available in an object- 
APIs, oriented programming language, the functions and capabili- 

Although in the preferred embodiment of the invention ties necessary to enable each application entity to determine 

the flexibility in the command format provided to the user is if and where it is participating in the dependency graph can 

implemented in the AAPI operator evaluator 69 that corre- be provided in a single class, referred to as an associative 

sponds to each command, it should be understood that this 30 variable class, from which each application entity created by 

feature of the present invention can be implemented in other the software system to represent a portion of the product 

ways. For example, the conversion between the format input design is made to inherit Each argument input to the design 

from the user and that required by the proprietary API can by the user is also defined as an application entity that 

be performed in the AAPI data component, so that the inherits from the associative variable class. The associative 

dependency graph will be generated in the format expected 35 variable class includes a field for identifying a pointer to a 

by the proprietary API. When the format conversion is particular data object in the dependency graph (e.g, data 

implemented in this manner, the AAPI operator evaluator objects 3-6, 17, 25 and 29 in FIG. 2). Thus, each application 

need not perform any format conversion. entity created by the software system to represent a portion 

V. Updating Software Application Entities To Reflect Par- of the product design, or to represent an argument input from 

ticipation In Dependency Graph 40 the user, uses this pointer to point to a particular data object, 

In addition to generating an AAPI wrapper around each if any, that represents it in the dependency graph. If the 

r^oprietaiyAPIm toeso^aresyst^^ pointer field is nil in a particular application entity, it 

also modifies the software application entities that are gen- indicates that the application entity bas not been assigned a 

erated by the software system to represent the product corresponding data object in the dependency graph, and 

design, so that each application entity knows if and where it 45 therefore, is not yet participating in the graph. If the pointer 

is participating in the dependency graph. For example, if the field has a value, the application entity is represented in the 

software system on which the present invention is installed graph by the data object pointed to. 

is a CAD system, the application entities generated thereby The associative variable class also provides two functions 

can include boxes, cylinders, and other structures that rep- that are passed to each of the application entities that inherit 

resent the product design. For example, in the illustrative 50 from it. The first function sets the above-described pointer 

example of FIG. 2, the result of evaluating the operator 7 to field to a particular value identifying the location of a 

insert a box is an application entity that represents the box, corresponding data object when the application entity is 

and whose description inherently includes the arguments added to the dependency graph. The second function 

(length, width, height and center position) used to define the retrieves the pointer value and returns it when the applica- 

box. 55 tion entity is questioned as to where it is present in the 

As discussed above, the present invention is preferably dependency graph. As stated above, in addition to applica- 

implemented in an object-oriented programming language. tion entities, generated by the software program, arguments 

Although other programming languages can be used to input to the system by the user are also represented as 

practice the present invention, object-oriented programming application entities that depend from the associative variable 

Languages are advantageous in mat they have capabilities eo class. Therefore, each of the application entities represented 

which allow for a simple modification to the application in the dependency graph as a data object depends from the 

entities created by the software system during a design associative variable class, so that each includes the data 

session to enable each application entity to understand if and object pointer field and the functions to set and retrieve the 

where it is participating in the dependency graph. Object- pointer value. 

oriented programming languages allow application entities 65 The capabilities provided to each of the application enti- 

having some common characteristics to be defined in a ties by the associative variable class are used in the creation 

common class. Referring to the illustrative dependency and management of the graph in the following manner, 
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making reference to the example shown in FIG. 2. Initially, ciative AH processor 71 creates a graph entity to represent 
the user enters a command to insert a box. The entry of this an operator in the dependency graph that corresponds to the 
command results in an AAPI 63 (FIG. 5) calling the asso- design action of the calling macro. At step 403, the method 
ciative API processor 71 in the manner described above. In then selects a first of the macro's arguments for processing, 
calling the API processor 71, the AAPI macro call 65 passes 5 As discussed above, each argument is passed to the asso- 
the processor each of the arguments associated with the ciative API processor 71 as an application entity that 
calling macro, Le., the length, width, height and center includes a pointer field indicating if and where the argument 
position for the box. Each of these arguments is passed in the is represented in the dependency graph by a data object 
form of an application entity that depends from the asso- In step 405, the method reads the data object pointer of the 
ciatiYC variable class. Thus, in order to determine the affect 10 selected argument to determine whether it is nil, and when 
of the macro call on the dependency graph, the associative it is, the method proceeds to step 407 wherein a graph entity 
API processor 71 queries each of the application entities that is created to represent a new data object in the dependency 
represents an argument to determine whether and where in graph, and the application entity representing the argument 
the graph each argument is represented. Since none of the is updated so mat its data object pointer points to the newly 
arguments was previously represented in the graph, each of 15 created data object After the creation of the data object in 
the application entities representing one of the arguments step 407, or if it is determined at step 405 that a data object 
includes a nil value in its data object pointer. Upon reading already exists for the argument, the method proceeds to step 
these nil pointers, the API processor 71 creates a new graph 409 wherein a relation is created between the data object and 
entity to represent a data object for each argument, and the operator created in step 401. In step 411, a determination 
instructs each of the argument application entities to set its 20 is made as to whether the argument being processed is the 
data object pointer to the memory location of its newly last argument associated with the calling macro, and when it 
created graph entity. The API processor then creates graph is not, the method returns to step 403 to select another 
entities representing the operator 7 for inserting the box and argument for processing. In this manner, the method pro- 
the relations 9-12 in (he manner discussed above. In ceeds through steps 403-411 to create the input relations and 
addition, the API processor 71 creates graph entities repre- 25 data objects associated with the operator created in step 401 
senting the relation 15 and the result data object 17. The and to connect them to the operator, 
processor 71 then instructs the operator 7 to evaluate itself, When it is determined at step 411 that the last argument 
resulting in a call to its AAPI operator evaluator 69. In the has been processed, the method proceeds to steps 413 and 
manner described above, the operator evaluator calls the 415 wherein a result data object and relation are respectively 
insert box proprietary API, which returns to the evaluator an 30 created for the operator. The method then proceeds to step 
application entity representing the box that it created. The 417 wherein the associative API processor 71 requests the 
operator evaluator 69 then updates the data object pointer in operator to evaluate itself. The evaluation, performed by the 
the application entity defining the box to point to the AAPI operator evaluator 69 calling its corresponding pro- 
memory location for the data object 17, thereby providing prietary API with an ordered list of data, returns a result in 
the application entity that defines the box with the informa- 35 the form of an application entity to the associative API 
tion relating to its participation in the dependency graph. processor 71. In step 418, the result is associated with the 
Continuing with the example relating to FIG. 2, the next result data object created in step 413 but updating the data 
command received from the user is to calculate the weight object pointer in the application entity that defines the result 
of the box. In response to this command, the corresponding Finally, in step 419, the processor 71 returns the application 
AAPI macro call 65 passes to the associative API processor 40 entity that defines the result to the macro whose call initiated 
71 the argument upon which the calculate weight function is the method. 

to be performed, i.e., the application entity defining the box. VTJL Evaluating The Dependency Graph 
The API processor 71 asks this application entity to specify In response to the processor 71 requesting evaluation of 
the pointer value that identifies its corresponding data object an operator in step 417 of the method of FIG. 6, argument 
in the dependency graph. Since such a data object was 45 collection and operator evaluator routines are called that are 
previously created, the address of data object 17 is returned generic to all operators, and that ensure that all of the 
to the processor 71. Hie processor 71 then updates the arguments required by the operator are up-to-date before 
dependency graph by generating graph entities representing calling the operator evaluator 69 of the evaluated operator, 
the calculate weight operator 19 and the relation 21. In the The steps of the argument collection routine are shown in 
graph entity that represents the relation 21, a pointer is 50 FIG. 7c Initially, a first argument associated with the 
updated to include the address of the memory location mat evaluated operator is selected for processing in step 501, and 
stores the graph entity that represents data object 17. In this a determination is made at step 502 as to whether this 
manner, the dependency relationship of the calculate weight argument is "out of synch**. The phrase out of synch is used 
operator 19 on the insert box operator 7 is reflected in the to indicate that the data object that represents the argument 
dependency graph. The associative API processor 71 also 55 is dependent upon at least one other graph entity that has 
creates new data objects 25 and 29, as well as their associ- been changed, but that has not yet been re-evaluated. Thus, 
ated relations, to complete the dependency graph in the rf the argument is out of synch, the method proceeds to step 
manner described above. 503 wherein updating of the argument is requested. After 
VL Associative API Processor Routine For Creating And updating is requested at step 503, or if it is determined at step 
Evaluating Dependency Graph 60 502 that the argument is not out of synch, the method 
The above-described capabilities of each argument and proceeds to step 504, wherein a determination is made as to 
application entity to understand if and where they are whether all of the arguments for the operator being evaluated 
participating in the dependency graph is utilized by the have been collected. When it is determined that they have 
associative API processor 71 during the creation of the not, the method returns to step 501 where a new argument 
dependency graph in the manner illustrated in FIG. 6, which 65 is selected for collection. In this manner, the method pro- 
illustrates the steps that the processor 71 performs when it is ceeds through steps 501-504 until all of the arguments for 
called by an AAPI macro. Initially, in step 401, the asso- the operator have been collected, and those that were out of 
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synch have been updated. The method then proceeds to step and non-directed operators to be implemented homoge- 

505 wherein the operator evaluate? 69 that corresponds to neously throughout a dependency graph, such that the 

the evaluated operator is called. results of directed operators can be provided as inputs to 

The steps of the operator evaluator routine are shown in non-directed operators, and vice versa. 
FIG. 7b. Initially, a first argument associated with the 5 It should be understood that in order to solve a group of 
evaluated operator is selected in step 506, and then in step interconnected non-directed operators, some solving engine 
507 the value associated with the selected argument is must be provided. Non-directed operations are also corn- 
retrieved from the data object pointer that represents the monly referred to as constraints, with a group of inter- 
argument in the dependency graph. The method then pro- dependent non-directed operations forming a constraint set. 
ceeds to step 507, wherein the argument value is cast into a 10 The present invention is directed to a method for represent- 
data type that is expected by the proprietary API that will be ing non-directed operators in a dependency graph, with or 
called by the operator evaluator. Each data object in the without directed operators, but is not directed to any par- 
dependency graph is generic, and does not contain informa- ticular engine for solving constraint sets formed by groups 
tion as to the format of the argument that it points to. For of non-directed operators. The present invention represents 
example, the argument could be an integer, an application 15 the structural dependency of non-directed operators, groups 
entity that defines a box, an application entity that defines a them together constraint sets in a manner described below, 
cylinder, etc. Therefore, before the operator evaluator calls and then provides the constraint sets to a constraint solving 
the API, it casts the argument into the data type expected by engine that solves them. 

theAPL Examples of non-directed operations (Le., constraints) 
At step 509, a determination is made as to whether all of 20 include algebraic constraints such as the example discussed 
the arguments to be passed to the API have been processed, above, geometric constraints between two objects, such as 
and when they have not, the method returns to step 506 establishing two lines to be parallel, perpendicular, etc., and 
wherein another argument is selected for processed. In this spacial constraints for two objects requiring that the objects 
m a nn er, the method proceeds through steps 506-509 to maintain some sort of spacial relationship. For example, the 
process all of the arguments associated with the operator. 25 present invention may represent the structural dependency 
When all of the arguments have been processed, the method of a group of simultaneous equations and can provide them 
proceeds to step 510, wherein the arguments are formatted together as a constraint set to a solving engine. However, the 
in the manner expected by the proprietary API to be called. present invention is not directed to any particular engine for 
As discussed above, in one embodiment of the invention, the solving the simultaneous equations, 
operator evaluator for an AAPI can provide additional 30 As should be appreciated from the foregoing, when the 
options to the user in the manner in which commands can be embodiment of the present invention that supports non- 
formatted. If the user command and its corresponding opera- directed operators is used, the software system on which the 
tor in the dependency graph are formatted differently from associativity subsystem of the present invention is installed 
the API, the method reformats the arguments in step 510 to will be provided with a constraint solving engine. The 
that expected by the API. After the arguments arc formatted, 35 present invention is not limited in the types of constraints 
the method proceeds to step 511 wherein the proprietary API that can be represented. However, any particular software 
that corresponds to the operator is called, and is passed the system on which the associativity subsystem of the present 
arguments ordered in the manner that it requires. The invention is installed may have a constraint solving engine 
proprietary API returns to the operator evaluator an appli- that is limited in the types of constraints it can solve. When 
cation entity that represents the result of the design action 40 this occurs, the present invention checks the design gener- 
taken by the APL At step 512, the operator evaluator updates ated by the user to determine whether each constraint set 
the data object pointer in the graph entity created for the formed in the design is valid, Le., is of a type that the 
operator result in step 413 of FIG. 6. constraint solving engine can form. If an unsupported con- 
VTH Representing Non-Directed Operations straint set is formed, the present invention detects this as an 

The foregoing discussion has related solely to directed 45 error condition in the manner described below, 

operations, which are represented in the dependency graph Since directed operators can only be evaluated in one 

of the present invention with directed operators. A directed direction, there are limits on the manner in which directed 

operator has a flow in one direction, from one or more inputs and non-directed operators can be connected in a single 

to an output However, the present invention can also be dependency graph. An input to a non-directed operator is 

employed in a software system that supports non-directed 50 considered to have a fixed value if it is the result of a directed 

operations. For example, a command may be executed that operator. Each non-directed operator must have at least one 

represents the relationship A=B*C. If this were a directed input that is not fixed. For example, for the non-directed 

operation, the user would only be able to edit the values of operation discussed above wherein A=B*C, both inputs B 

B and C and the directed operator would produce the and C cannot be fixed, because if they were, the operator 

appropriate value for A. However, if the command was a 55 would not be non-directed in that the required relationship 

non-directed operation, the user would have the option of cannot be maintained if the value of A were altered, because 

alternatively specifying a value for A, and having the system both B and C are fixed. Thus, the inputs B and C could not 

determine values ofB and C so that their product equaled the bom be provided from directed operators, because both 

value of A. A non-directed operation can propagate a change would be fixed, leading to an over-constrained case or error 

from any of its parameters, and there is no strict concept of 60 condition. However, so long as one of inputs B and C is 

inputs and outputs. unconstrained, for example being provided from another 

The present invention provides the capability to represent non-directed operator, no error condition occurs because as 

both directed and non-directed operations in a single depen- the value of A is altered, the unconstrained input B or C can 

dency graph, with directed operations being represented by be altered in the corresponding manner, 

directed operators, and non-directed operations being rep- 65 Another limitation placed on the use of directed and 

resented by non-directed operators. Subject to some limita- non-directed operators in a single dependency graph is that 

tions discussed below, the present invention enables directed a cycle should not be formed in a graph to include any 
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directed operators. As should be understood by those skilled 
in the art, a cycle in a graph occurs when the tracing of any 
valid flow path through the graph from a start points leads 
back to the start point Although cycles can validly exist that 
include only non-directed operators, any cycle that includes 
a directed operator results in an over-constrained error 
condition. 

When a non-directed operation is performed in a design, 
a checking routine of the present invention analyzes the 
dependency graph to determine whether a corresponding 
non-directed operator can be added without violating one of 
the above-described limitations. In particular, the routine 
ensures that the non-directed operator is not over- 
constrained and has at least one input whose value is not 
fixed. Additionally, the routine ensures that the adding of the 
non-directed operator does not result in the formation of a 
cycle in the graph that includes a directed operator. This is 
accomplished by the routine beginning at the added non- 
directed operator and walking through each valid path of the 
dependency graph to determine whether any of those paths 
arrives back at the non-directed operator being added. If 
either of the two prohibited conditions occurs, an error 
signal is generated such that the non-directed operator 
cannot be added to the dependency graph in the manner 
attempted by the user. If no error occurs, the non-directed 
operator is added to the graph. 

As discussed above, the present invention is not directed 
to any particular engine for solving a set of constraints. 
Rather, the present invention is directed to the graphical 
representation of designs that may include sets of non- 
directed constraints. In the manner discussed below, the 
present invention determines the boundaries of each non- 
directed constraint set in a design, and provides those 
constraint sets to the solving engine for simultaneous reso- 
lution. Each cycle that includes only non-directed operators 
forms a constraint set, with the boundaries of the constraint 
sets being determined by the location of directed operators 
in the graph, or the boundaries of the graph itself. 

1. Symbolic Evaluation Pass 

As discussed above in connection with FIGS, la-lb, 
when the associative API processor 71 requests that an 
operator in the dependency graph be evaluated, an evaluate 
method is called that is generic to all operators. The evaluate 
method is called by a graph manager 75 (FIG. 5), which is 
a software entity described in further detail below and 
performs tasks involved in managing the dependency graphs 
created in accordance with the present invention. The basic 
steps performed by the evaluation method were described 
above in connection with FIGS, la-lb. A specific imple- 
mentation for this method will now be described for the 
embodiment of the present invention that supports the use of 
non-directed operators. In accordance with this embodiment 
of the invention, a two-pass method is executed with respect 
to the dependency graph. During a first pass, referred to as 
the symbolic pass, the graph is interrogated to form a list of 
operators to be evaluated, as well as the order in which the 
list should be evaluated. The operators included in the list 
are cither single directed operators, or constraint sets of 
non-directed operators that should be evaluated simulta- 
neously by the constraint solving engine. The second step is 
the evaluation of each of the operators in the order specified 
by the list formed during the symbolic pass, and is referred 
to as the evaluation pass. 

The symbolic pass is represented by the flowchart of FIG. 
8, and is called whenever the associative API processor 71 
requests that an operator in the dependency graph evaluate 
itself. Initially, in step 800 a stack is opened up for the 
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operator evaluation list which is created during the symbolic 
pass to define the order in which the operators and sets of 
constraints are to be evaluated. The stack created for this 
purpose is a first-in first-out stack onto which operators and 

5 constraint sets are pushed and popped in the manner 
described below. After the stack list is opened, the method 
proceeds to step 802 wherein an edited (i.e., out of synch) 
data object for the operator being evaluated is selected for 
processing. Typically, the associative API processor 71 will 

xo not demand the evaluation of an operator unless one of its 
data objects has been edited, requiring re-cvaluation. 
However, when the visual editing capabilities of the present 
invention described below are employed, the operator itself 
may be changed without changing one of its data object 

15 inputs. If mis occurs, the present invention establishes each 
of the data objects as being out of synch, so that each will 
be processed during the symbolic pass. 

In step 804, the dependency graph is interrogated to form 
a list of all operators that are directly dependent on the data 

20 object selected for processing in step 802. A directed opera- 
tor is directly dependent upon a data object when the data 
object is provided as an input to the operator, whereas a 
non-directed operator is directly dependent on a data object 
when it is directly connected to the data object in any 

25 fashion. No attempt is made in step 804 to propagate through 
the dependency graph and locate other operators that are 
indirectly dependent on the data object in that they may be 
affected by a change to it, because those operators will be 
identified through the recursive nature of the symbolic pass 

30 in the manner described below. 

In step 806, one of the operators identified in the list 
formed during step 804 is selected for processing, and in 
step 808, a determination is made as to whether this operator 
is directed. When the selected operator is directed, the 

35 method proceeds to step 810, wherein a routine for process- 
ing directed operators (FIG. 9) is called. Conversely, when 
the selected operator is non-directed, the method proceeds to 
step 812, wherein a routine for processing non-directed 
operators (FIGS. lOa-lOfc) is called. The operator process- 

40 ing routines push the processed operators onto the operator 
evaluation stack in the proper order for evaluation, and are 
discussed in detail below. 

When the appropriate processing routine called in either 
step 810 or 812 to handle the processing of the most recently 

45 selected operator returns to the symbolic pass, the method 
proceeds to step 814, wherein a determination is made as to 
whether any operators in the list formed in step 804 remain 
to be processed, and when any remain, the method returns to 
step 806 wherein another operator is selected for processing. 

50 In this manner, the method proceeds through steps 806-814 
to process all of the operators in the list created in step 804 
that are directly dependent upon the first edited data object 
selected for processing in step 802. 
When it is determined at step 814 that no operators remain 

55 for processing, the method proceeds to step 816, wherein a 
determination is made as to whether any edited data objects 
for the operator whose evaluation called the method remain 
for processing, and when at least one remains for processing, 
the method returns to step 802, wherein another edited data 

60 object is selected for processing. In this manner, the method 
proceeds through steps 802-816 until all of the edited data 
objects for the operator being evaluated have been pro- 
cessed. When it is determined at step 816 that all of those 
data objects have been processed, the method terminates. 

65 The direct operator processing routine called in step 810 
of FIG. 8 is represented by the flowchart of FIG. 9. Initially, 
in step 820 the routine determines whether the operator 
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being processed has already been pushed onto the operator 
evaluator stack, and when it has, the routine simply termi- 
nates. When it is determined that the operator has not already 
been pushed onto the stack, the method proceeds to step 822, 
wherein one of the data objects input to the directed operator 
is selected for processing. In step 824, a determination is 
made as to whether the selected data object is out of synch, 
and when it is, the method proceeds to step 826 wherein the 
operator that sources that data object is selected for process- 
ing. The method then proceeds to step 828, wherein a 
determination is made as to whether the operator selected for 
processing in step 826 is a directed or non-directed operator. 

When the source operator is a non-directed operator, the 
method proceeds to step 830 wherein the non-directed 
operator processing routine is called to process that operator 
in the manner discussed below. Conversely, when the source 
operator is directed, the directed operator processing routine 
is re-called to process that operator in step 832. In this 
manner, the directed and non-directed operator processing 
routines are executed in a recursive manner to step through 
the dependency graph and process all of the operators that 
require revaluation to generate the data objects operated 
upon by the operator whose evaluation initiated the call to 
the symbolic evaluation pass (FIG. 8). It should be under- 
stood that the evaluation or re-evaluation of the dependency 
graph should be performed by evaluating the operators or 
sets of constraints on the left-hand side of the graph first, and 
the proceeding through the graph in a left- to-right manner. 
By executing the operators in this manner, it will be ensured 
that no operator is evaluated until all operators that affect its 
data objects have been updated 

When it is determined at step 824 that the selected data 
object of the operator being processed is not out of synch, or 
after the appropriate routine has been called to process the 
source operator for that data object in either of steps 830 or 
832 when the data object is out of synch, the method 
proceeds to step 834, wherein a determination is made as to 
whether any data objects for the selected operator remain to 
be processed. When it is determined at step 834 that at least 
one data object remains to be processed, the routine returns 
to step 822, wherein another data object is selected for 
processing. In this manner, the method proceeds through 
steps 822-834 to process all of the data objects for the 
operator whose evaluation caused the symbolic evaluation 
pass (FIG. 8), and thus the directed operator processing 
routine, to be called 

Finally, when it is determined at step 834 that no data 
objects remain to be processed for the operator whose 
evaluation called the processing routine, the operator is 
pushed onto the operator evaluation stack in step 836. 

The recursive nature of the directed and non-directed 
operator processing routines ensures that the operators in the 
dependency graph will be evaluated in the correct order to 
achieve the above-described desired results. As seen from 
the foregoing description of FIG. 9, an operator is not 
pushed onto the evaluation stack in step 836 until it is 
determined at step 834 that all of its data objects have been 
processed. Furthermore, during the processing of the data 
objects, for each that is out of synch, the directed or 
non-directed operator processing routine is called to process 
the operator that sources the data object. When the process- 
ing routine of FIG. 9 is called to operate upon to those source 
operators, a determination is similarly made to ensure that 
each of its data objects are up to date, and when any is not, 
the routine is called again to process that source operator. 
Because of this recursive nature of the routine, each operator 
that must be evaluated to provide an updated data object to 
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another operator is pushed onto the stack in step 836 during 
its corresponding execution of the routine before the opera- 
tor that responds to its data object, and therefore, will be 
evaluated before any operator that is dependent upon its 

5 result. The operator whose evaluation initially called the 
symbolic pass routine (FIG. 8) is the first to be processed, 
and therefore, is at the highest level of the recursive process 
of the routine. Therefore, this operator is pushed onto the 
operator evaluator stack only after each of the operators that 

10 produce a result that it depends upon have been pushed onto 
the stack during previous iterations of the recursire process. 

The non-directed operator processing routine is repre- 
sented by the flowchart of FIG. 10. As with the directed 
operator routine of FIG. 9, the routine of FIG. 10 is initially 

15 called when the associative API processor 71 demands the 
evaluation of an operator in the dependency graph. In step 
840, a determination is made as to whether the operator has 
already been pushed onto the operator evaluator stack as part 
of a previously defined constraint set, and when it has, the 

20 routine terminates. If the operator is not already on the stack, 
the method proceeds to step 842, wherein a determination is 
made as to whether a constraint set is currently open, and if 
one is not, the method proceeds to step 844 wherein a 
constraint set is opened. 

25 As discussed above, the present invention may be 
installed on a software system that includes a constraint 
evaluator engine for evaluating constraint sets that can 
include multiple non-directed operators. In order to evaluate 
such a constraint set correctly, the engine should receive the 

30 the set of tightly coupled non-directed operators as a group. 
Therefore, when evaluating a dependency graph that 
includes both directed and non-directed operators, the 
dependency graph is organized by the symbolic pass of FIG. 
8 so that the constraint sets can be provided to the engine as 

35 a group. 

As discussed above, directed operators are simply pushed 
onto the operator evaluator stack in their proper order for 
evaluation due to the recursire nature of the directed opera- 
tor processing routine. However, a constraint set is not 

40 pushed onto the operator evaluator stack until the entire set 
has been processed. Only after each of its non-directed 
operators has been processed is the constraint set pushed 
onto the operator evaluator stack. Each constraint set is 
pushed onto the stack in the proper evaluation order relative 

45 to other constraints sets and directed operators in the depen- 
dency graph, which may occur well after the set was opened. 

After a constraint set is opened in step 844, or when it is 
determined that one was already opened in step 842, the 
method proceeds to step 846 wherein the non-directed 

50 operator being processed is added to the open constraint set 
Thereafter, in step 848, one of the data objects associated 
with the non-directed operator is selected for processing. 
The method then proceeds to step 850, wherein a list is 
formed of the operators that directly source the data object 

55 selected in step 848. Non-directed operators directly source 
the data object if they are directly connected to it, whereas 
directed operators directly source the data object if it is then- 
result data object 

In step 852, a determination is made as to whether the list 

60 of direct source operators generated in step 850 includes a 
directed operator No more than one directed operator may 
source any single data object When it is determined that the 
list of direct source operators includes a directed operator, 
the method proceeds to step 854, wherein a determination is 

65 made as to whether the selected data object is out of synch. 
When the data object is out of synch, the method proceeds 
to step 856, wherein the directed operator processing routine 
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of FIG. 9 is called to process the directed operator that 
sources the selected data object. 

As discussed above in connection with FIG. 9, the calling 
of the directed operator processing routine will result in the 
processing of not only the directed operator that it is initially 5 
called to process, but also all other operators, directed or 
non-directed, that generate data objects on which it directly 
or indirectly depends. Thus, by calling the directed operator 
processing routine prior to completing the processing of the 
constraint set, the non-directed operator processing routine 10 
of FIG. 10 ensures that any directed operators that feed the 
constraint set will be placed upon the operator evaluator 
stack before the constraint set Since the output of a directed 
operator will be fixed with respect to the constraint set, the 
method of FIG. 10 ensures that any fixed values to the 15 
constraint set are evaluated before the constraint set is 
passed to the constraint solving engine for resolution. 

When either the directed operator processing routine 
returns to step 856, it is determined at step 854 that the 
selected data object is not out of synch, or it is determined 20 
at step 852 that the list of source operators generated at step 
850 does not include a directed operator, the method pro- 
ceeds to step 858. In step 858, a determination is made as to 
whether the list of source operators generated in step 850 
includes a non-directed operator, and when it does, the 25 
method proceeds to step 860, wherein a non-directed opera- 
tor is selected for processing, and then to step 862 wherein 
the non-directed operator processing routine is called for the 
selected operator. 

As should be appreciated from the foregoing, like the 30 
routine of FIG. 9 for processing directed operators, the 
non-directed operator processing routine of FIG. 10 operates 
in a recursive manner, However, there is a significant 
difference between the recursive nature of these routines. As 
discussed above, the recursive nature of the directed opera- 35 
tor routine of FIG. 9 is the technique by which the directed 
operators are pushed onto the operator evaluator stack in the 
order in which they are to be executed. By contrast, and as 
should be seen from the above-described steps of the non- 
directed operator processing routine, when non-directed 40 
operators are processed, they are not individually pushed 
onto the operator evaluator stack, but rather, are simply 
added to an open constraint set The order in which the 
non-directed operators are placed into the constraint set is 
not significant, since the constraint resolving engine will 45 
operate upon all of the non-directed operators in the set 
simultaneously. Therefore, the recursire nature of the routine 
shown in FIG. 10 is employed solely to ensure that all of the 
non-directed operators in a constraint set are added to the 
set, and is not employed to ensure any order in which they 50 
are added to the set because that order is irrelevant. 

After the non-directed operator processing routine returns 
from processing the non-directed operator selected in step 
860, the method proceeds to step 864. In step 864, a 
determination is made as to whether any non-directed opera- 55 
tors remain for processing, and when at least one remains to 
be processed, the method returns to step 860 wherein 
another non-directed operator is selected for processing. In 
this manner, the routine steps through each of the non- 
directed operators in the list of source operators generated in 60 
step 850, until it is determined in step 864 that all of the 
non-directed operators have been processed. 

When it is determined in step 864 that no non-directed 
operators remain to be processed, or when it is determined 
at step 858 that the list of source operators does not include 65 
any non-directed operators, the method proceeds to step 866. 
In step 866, a determination is made as to whether any data 



12/10/2003, EAST 



711 

24 

objects remain to be processed for the non-directed operator 
for which the routine was called, and when at least one data 
object remains to be processed, the method returns to step 
848 wherein another data object is selected for processing. 
In this manner, the method proceeds through steps 848-866 
until all of the data objects for the operator for which the 
routine was called have been processed. 

When it is determined at step 866 that no data objects 
remain to be processed, the method proceeds to step 868 
wherein a determination is made as to whether the non- 
directed operator for which the routine was called opened a 
constraint set. This step is included in the routine due to the 
recursire nature of its execution. When the routine is 
executed for an operator that did not open the currently open 
constraint set, other non-directed operators may remain to be 
processed that should be added to the constraint set, and 
therefore, the constraint set should not yet be closed and 
added to the operator evaluator stack. Therefore, when it is 
determined at step 868 that the calling operator did not open 
the constraint set, the method simply terminates, which will 
return to step 858 of the next highest level in the recursire 
execution of the routine. 

When it is determined at step 868 that the calling operator 
opened the currently open constraint set, the method pro- 
ceeds to step 870 wherein a determination is made as to 
whether the constraint set is empty, and when it is, the 
method proceeds to step 872 where the constraint set is 
deleted prior to termination of the method. When the con- 
straint set is not empty, the method proceeds to step 874 
where the constraint set is closed, and then in step 876 the 
closed constraint set is pushed onto the operator evaluator 
stack as its most recent entry prior to terrnination of the 
method. 

2. Evaluation Pass 

As should be appreciated from the foregoing, the recur- 
sive execution of the directed and non-directed operator 
processing routines of FIGS. 9 and 10 during the symbolic 
pass places directed operators and constraint sets of non- 
directed operators onto the operator evaluator stack in the 
order in which they should be evaluated. Therefore, the 
routine that executes the actual evaluation pass to update the 
graph is straightforward, and is represented by the flowchart 
of FIG. 11. 

Initially, in step 880 the method executes the operators 
and constraint sets in the order specified by the stack. The 
evaluation routine implemented for each operator and con- 
straint set was discussed above in connection with FIGS, la 
and lb and involves the collection and formatting of 
arguments, and then calling the appropriate proprietary APIs 
to update the design. The method then proceeds to step 882, 
wherein the stack is saved for potential re-use in connection 
with one embodiment of the invention. Depending upon the 
nature of the changes made by the user, it may be possible 
to re-evaluate the graph two or more times without requiring 
separate symbolic passes for each re-evaluation. In 
particular, if a user re-edits any leaf node data objects that 
are input to the graph, the symbolic pass need not be 
re-executed because the results on the operator evaluator 
stack will be identical. Additionally, if the only change to the 
design is the editing of data objects that are inputs to directed 
operators that are already on the operator evaluator stack, the 
symbolic pass again need not be executed. 
IX. Integration Process 

As should be appreciated from the foregoing, the present 
invention can be used in conjunction with any software 
system composed of functions, following the installation of 
the software of the present invention, and the execution of 
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an integration process on the software system. The associ- 
ated API processor function and the associative variable 
class are generic with respect to the specifics of the software 
systems on which the present invention can be installed, and 
therefore, are provided in the installed software. The 
installed software executes an integration process shown in 
FTG. 12. The details of each step of the process were 
described above. Initially, in step 301 the class definition of 
each application entity generated by the software system to 
represent a portion of the product design, as well as those 
that represent the arguments input to the design, are modi- 
fied to inherit from the associative variable class so that they 
have the above-described capabilities used in determining if 
and where they are participating in the dependency graph. 
Next, an AAPI is generated for each proprietary API in the 
software system in step 302. 

Thereafter, the user interface is modified at step 303 so 
that in response to commands received from the user, the 
user interface calls the AAPIs generated in step 302, rather 
than directly calling the APIs of the software system. Finally, 
in step 304 an initialization function is executed which 
generates the graph manager, and which causes the graph 
manager to create the software entities that form the entries 
of the hash table. 

Once the integration process of FIG. 12 is executed on a 
software system, the system is provided with the capabilities 
of the present invention in a manner that is transparent to the 
user, and does not require special user training. In addition, 
it should be appreciated that the operation of the integration 
process on a software system provides parametric capability 
to the system, even if no such capability was provided in the 
proprietary commands and corresponding APIs in the sys- 
tem. As discussed above, this characteristic of the present 
invention facilitates third parties providing add-on capabili- 
ties to the software system, because additional commands 
provided by the third party need not be integrated into the 
command set of the software system to provide parametric 
capabilities. 

X. Parametric Capabilities 

As discussed above, one of the advantages of the present 
invention is that when modifications are made to the product 
design, the modifications are incorporated into the design 
using the dependency graph so that only those operators 
with results that are affected by the modification are 
re-evaluated. This aspect of the present invention is con- 
trolled by the graph manager 75 (FIG. 5). The graph 
manager is a software entity that receives inputs from the 
user interface 37 to determine when modifications have been 
made to the product design. Most CAD systems include a 
parametric interactor which, after an application entity (e.g., 
a box, cylinder, etc.) has been added to the design, allows the 
user to make modifications to the parameters relating 
thereto, e.g., changing the length, width and/or height of a 
previously created box. 

In conjunction with the present invention, a change to a 
parameter in the design results not only in a change to the 
product design 45 (FIG. 3) output from the system, but also 
modifies at least one argument associated with a data object 
in the dependency graph. Thus, when the software system 
provides a parametric interactor that allows a user command 
to change a parameter of the design, the present invention 
associates the command received from the user with the data 
object that represents the changed parameter in the depen- 
dency graph. Specifically, when the user enters a command 
to change a parameter, the new argument is passed from the 
user interface 37 to the graph manager 75, which updates the 
memory location pointed to by the corresponding data object 
in the dependency graph to reflect the changed argument 



9,711 

26 

Thereafter, the graph manager 75 executes the two pass 
process for propagating the change into the product design 
45 discussed above in connection with FIGS. 8-11. 
In one embodiment of the invention, changes to existing 
5 design parameters are not immediately incorporated into the 
product design. Rather, updates to the design are not imple- 
mented unless and until the user requests recalculation. This 
feature is advantageous when, for example, a user wishes to 
change several parameters before updating the design, 

1Q because the system conserves resources by not recalculating 
after each parameter change. When the user requests 
recalculation, the graph manager 75 instructs the associative 
API processor 71 to cause the operators in the dependency 
graph that depend upon a changed parameter to re-evaluate 
themselves in the manner described above. In one embodi- 

15 ment of the invention, two modes of recalculation are 
provided. A first mode is known as regeneration forward and 
involves the recalculation of all operators that are dependent 
upon a change parameter. The second mode is known as 
regeneration on demand and is demand driven. In this 

20 second mode, the user can specify only a subset of the design 
to be updated. For example, the user may request to see the 
results of a parameter change on only a portion of the design. 
Making reference to the illustrative example of HG. 2, the 
user could for example make a change to the length param- 

25 eter associated with data object 3, and request to see the 
impact that this parameter change would have with respect 
only to the generated box. If the user made such a demand, 
the graph manager 75 would instruct the associated API 
processor 71 to cause only the operator 7 to re-evaluate 

30 itself. Thus, although the operator 19 is also dependent upon 
the parameter associated with data object 3, the graph 
manager would not instruct the associative API processor 71 
to cause operator 19 tore-evaluate itself because this was not 
demanded by the user. 

35 XL Hierarchical Operators 

In one embodiment of the invention, a capability is 
provided to represent operations performed by the user in a 
hierarchical manner in the dependency graph. Hierarchical 
operators are created that each represents one or more lower 

40 level operators arranged in some logical manner to represent 
a design goal of the user. As discussed in more detail below, 
the hierarchical capability can be employed by the user to 
group together in a hierarchical manner multiple commands 
of the software system on which the associativity subsystem 

45 of the present invention is installed, and can also be used by 
the software system to group a command and one or more 
subcommands in a single hierarchical group. 

The hierarchical capability of the present invention allows 
a set of low level design operations to be organized and 

50 represented as a single higher level goal oriented activity of 
the user in the dependency graph. For example, a user 
designing a rotor for an automobile on a CAD system may 
create a first hierarchical operator by grouping together all of 
the low level operators used to define the lug connections for 

55 the rotor, and a second hierarchical operator by grouping 
together the low level operators used to add cooling chan- 
nels into the rotor. By grouping together a number of low 
level operators and representing them with a single hierar- 
chical operator, the dependency graph generated for the 

60 design can be simplified to represent the goal oriented 
activity of the user more meaningfully. Additionally, once 
they are formed, the hierarchical operators can be copied for 
use in other places in the design so that the low level design 
operations that created the hierarchical group need not be 

65 duplicated. 

When the associativity subsystem of the present invention 
is integrated into a software system, the resulting associative 
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system can also implement the hierarchical capability to hierarchical operator is not shown to simplify the graph. The 

group together a command with a corresponding series of data object 712 that represents the box is connected through 

subcommands that are typically executed by the user along two relations 730 and 731 to represent that this data object 

with the command to define certain characteristics of the is provided to two separate operators (ix., 714 and 71*) 

command. For example, many CAD systems employ 5 internal to the hierarchical operator 726. The result of the 

features, which are a form of higher level geometric mod. h {""1** T?^ iS % Tt^L^ 

eling that correlates to the design goals of the user, but ob J e * ?4 output from operator 716 f which represents the 

require the execution of subcormWds with the feature to ^plication entity defining the box having the countersunk 

define the specifics of die design goal. Employing ; the °£ be dated from a comparison of me 

hierarchical capability of the present invention a CAD io d ^ g^T^f HGS . 16 and 17, the hierarchical 

system on which the associativity subsystem of the present operator capability of the present invention allows for the 

invention is installed can represent high level features in the representation of the user's design intent at a higher level, 

dependency graph using a hierarchical operator, rather than without cluttering the dependency graph with a number of 

requiring that each feature be represented by separate opera- operators that are merely tangential to the user's intent 

tors for the main command and all of its supporting sub- 15 ^ software system on which the associativity subsystem 

commands that may be required to define the potentially 0 f me present invention can be integrated may include a 

complex geometric modeling function performed by the number of hierarchical features that each may be desirable 

feature. to represent in the dependency graph with a single hierar- 

An example of a common CAD feature is a hole, of which chical operator. For those features, the software system can 

there are many different types. FIG. 15 shows an example of 20 employ the hierarchical operator capability of the present 

a countersunk hole 700 provided in a box 702. To insert the invention in a manner discussed below to represent those 

countersunk hole in the box 702, the user specifies a number features in a hierarchical manner. This capability is particu- 

of defining parameters, including a face datum 704 into larly useful in connection with commands that require the 

which the hole is to be provided, the position of the hole execution of a feature API to implement the user's design 

center on the face datum, the depth 706 of the hole, the 25 goal, and also several additional APIs relating to subcom- 

radius R 2 of the hole, the radius R t of the countersink, and mands that define the data on which the API operates. The 

the angle 9 of the countersink. These parameters are speci- hierarchical operator capability of the present invention 

fied by executing a group of subcommands along with the allows the group of multiple APIs to be represented as a 

feature command for creating the countersunk hole. single operator which more accurately represents the design 

If the hierarchical capability of the present invention were 30 intent of the user, 

not employed, the design action of a u ser defining a box with As discussed below, in one embodiment of the invention, 

a countersunk hole would be represented by a dependency the dependency graph can be edited in a graphical mode, 

graph such as the one shown in FIG. 16. The output of When this capability is employed, the user is provided with 

operator 716 is a data object 724 that represents the resulting flexibiKty as to the level of detail in the dependency graph 

application entity defining the box with a countersunk hole. 35 representation of the design. For example, for the depen- 

As shown, box itself is represented by a data object 712 that dency graph of FIG. 17 in which the hierarchical operator 

is the result of a box operator 710 having a plurality of 726 is used, the user may desire to view the graph in more 

relations and data objects as inputs. The insertion of the detail, and may select a different viewing mode wherein the 

countersunkhole in the box is represented by three operators hierarchical operator 726 is opened up to reveal the more 

714-716 that correspond to the feature command and two 40 detailed representation of the hierarchical operator shown in 

supporting subcommands. The operator 714 is connected to FIG. 16. When this occurs, some demarcation of the hier- 

the data object 712 representing the box, and represents a archy may be provided in the more detailed representation, 

subcommand executed by the user to select the top face of such as by drawing a dotted line around graph elements that 

the box as the portion thereof into which the countersunk are included within a single hierarchical block that has been 

hole is to be provided. The result of operator 714 is the top 45 opened up. 

face of the box. Operator 715 receives this result and When a hierarchical operator is created for the dep en- 
represents a subcommand executed by the user to select the dency graph, the present invention provides a scheme for 
datum for the top face to receive the countersunk hole. Hie defining its inputs and outputs. In this manner, clear bound- 
result of operator 715 is input to the countersunk hole aries are defined for each operator in the dependency graph 
operator 716, which represents the feature command. In 50 so that relations do not cross hierarchical boundaries. In 
addition to the datum input, the countersunk hole operator addition, because the user is provided with the capability to 
also is connected to data object 718 that represents the open up a hierarchical operator to view its more detailed 
location of the hole, data object 712 representing the solid representation, each level of the hierarchy below its top level 
(i.e,, the box into which the hole is to be provided), and data should also be able to obtain its inputs and outputs from 
objects 720-723 that respectively represent the radiuses R lt 55 other graph data objects without having a relation that 
R 2 , the angle 0, and the depth for the countersunk hole. crosses a hierarchical boundary. This is achieved by ensur- 
When the hierarchical capability of the present invention ing that an input or output is provided from each hierarchical 
is employed, the dependency graph that represents the operator for every one of its internal data objects that is input 
above-described design action can be generated in a manner from, or output to, an operator in the dependency graph that 
shown in FIG. 17. The operators 714-716 of FIG. 16 are 60 is outside the boundary of the hierarchical operator. By 
represented by a single hierarchical operator 726, which carefully managing the visibility of data objects across 
represents the creation of a countersunk hole in the box. The hierarchical boundaries, the re-use of hierarchical operators 
hierarchical operator 726 is shown as having two inputs that in other places in the design is facilitated, and support is 
import data object 712 that represents the box into the provided for the code generation feature of the present 
hierarchy for connection to internal operators 714 and 716, 65 invention discussed below. 

and a single result data object 724. Each of the data objects The manner in which visibility of data objects shared by 

that is input to the operators 714-716 but is internal to the more than one operator across a hierarchical boundary is 
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maintained is analogous to the manner in which variables 
are scoped across functions in a standard programming 
language such as C. Two criteria are established for ensuring 
the management of data objects across hierarchical bound- 
aries. First, if a hierarchical operator seeks to reference 
(either as an input or output) a data object that is referenced 
by another operator is outside of its hierarchical boundary, 
the data object included in the argument list far the hierar- 
chical operator. Second, the relationship between the hier- 
archical operator and the other operator that references the 
data object is provided in a parent function that contains both 
operators. The parent function can be a higher level hierar- 
chical operator that contains both, or can be the root of the 
dependency graph itself. 

To facilitate management of data objects across hierar- 
chical boundaries, two additional software entities are cre- 
ated for hierarchical operators. The first is an input/output 
(10) port created for each input and output that crosses the 
hierarchical boundary. The second is a list of the 10 ports for 
the hierarchical operator, referred to as an IO_OP. 

As discussed above in connection with the comparison of 
the dependency graphs shown in FIGS. 16 and 17, in one 
embodiment of the present invention, the only data objects 
ported (ie., brought out externally as an input or output) 
from a hierarchical operator are those that are referenced as 
inputs or outputs from an operator that is outside the 
boundary of the hierarchical operator. Thus, because data 
objects 718 and 720-723 (FIG. 16) are only internal to the 
hierarchical operator 726, they are not ported from the 
hierarchical operator to be represented in the dependency 
graph of FIG. 17 to clarify and reduce the complexity of that 
graph. In an alternate embodiment of the invention, all of the 
data objects input to each hierarchical operator, even those 
not souxced from another operator, can be ported from the 
hierarchical operator and represented in the dependency 
graph. 

As discussed above, each hierarchical operator has an 
IO_OP list that identifies its 10 ports. This list is dynamic, 
and additional ports are added as needed when operators are 
added to the design that reference a data object previously 
internalized within the hierarchical operator. The dynamic 
nature of the IO_OP list makes it unnecessary to port all 
inputs and outputs out of the hierarchical operator, which as 
discussed below, would be disadvantageous with respect to 
the size and clarity of the resulting dependency graph. 

As should be appreciated from the foregoing, the specific 
entries, in the IO_OP for a hierarchical operator are depen- 
dent upon the context of the design in which the hierarchical 
operator is employed. If a hierarchical operator were created 
to generate a countersunk hole as described above in con- 
nection with the example of FIGS. 15-17, that hierarchical 
operator can be copied by the user and used in a different 
portion of the design. Each instance of the hierarchical 
operator in the design can be different in terms of the inputs 
and outputs scoped out to other operators in the dependency 
graph, requiring a different IO_OP for each instance of the 
hierarchical operator. For example, if the countersunk hole 
hierarchical operator 726 was replicated in the design, the 
data object 723 (FIG. 16) that defines me depth of the hole 
could be provided as the result of an operator outside the 
boundary of the countersunk hole hierarchical operator. For 
that instance of the hierarchical operator, the data object 723 
would be exported from the hierarchical operator by creating 
an 10 port for it, and including the 10 port in the KL_OP for 
that instance of the hierarchical operator. 

An example of the 10 ports created for a hierarchical 
operator is described making reference to FIG. 18, which 
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shows conceptually how the 10 ports are created for the 
hierarchical operator of FIG. 17. It should be understood that 
although FIG. 18 is shown in the form of a dependency 
graph, the 10 ports and supporting operators are not actually 

5 represented in the dependency graph because they do not aid 
in representing the design goal of the user. 

As is discussed in more detail below, the 10 ports and 
I0„0P for each hierarchical operator are created by the 
graph manager 75 (FIG. 5). Each time an internal data object 

10 for a hierarchical operator is referenced (ie., input to or 
output from) outside of the hierarchy, an 10 port is added to 
the I0_0P to represent the porting of the data object outside 
the hierarchy. This is shown conceptually in FIG. 18, 
wherein four 10 ports are formed for the Merarchical opera- 
is tor 726 to port its internal data objects that are referenced 
outside the hierarchy. Each 10 port includes a data object 
and an equality operator. An equality operator is a graph 
entity like other operators, and represents that two data 
objects are to be simply equated so that the data object 

20 coupled to the output of an equality operator is set equal to 
the value in the data object coupled to the input of the 
equality operator. 

The 10 ports for hierarchical operator 726 include two 
input ports 730 and 736. Input port 730 includes a data 

25 object 730A and an equality operator 730B. The equality 
operator is further connected to an internal data object 732 
that is created to represent the data input to the top of face 
operator 714. Similarly, 10 port 736 includes a data object 
736A and an equality operator 736B that is connected to a 

30 data object 740 created to represent the data input to the 
solid relation of the countersunk hole operator 716, 

The input ports perform the function of importing data to 
the data objects internal to the hierarchical operator that are 
accessed across the hierarchical boundary. The data objects 

35 730A and 736A provide ports which can be connected at the 
parent level to the operators that source the data objects from 
outside the hierarchy. As described above, the parent level 
can be the root of the design as in the example of FIG. 18, 
or can alternatively be another hierarchical operator mat 

40 includes the one from which the input is being ported, as 
well as the operator that sources its data object 

In FIG. 18, two separate 10 ports are formed to respec- 
tively import the data object 712 to the top face operator 714 
and the solid relation of the countersunk hole operator 716 

45 internal to the hierarchical operator 726. In one embodiment 
of the invention, separate 10 ports are formed for two data 
objects such as these within a hierarchical operator that are 
referenced to a single data object across the hierarchical 
boundary. Providing separate 10 ports facilitates the capa- 

50 bility of allowing the user to copy a previously created 
hierarchical operator for use in a different portion of the 
design. Particularly, two internal data objects in a hierarchi- 
cal operator may be coupled to a single data object across the 
hierarchical boundary in one instance of the hierarchical 

55 operator in the graph, while in another instance those 
internal data objects may be coupled to separate data objects 
outside the hierarchical boundary. If separate IO ports were 
not created to separately port these internal data objects, the 
hierarchical operator could not be replicated and used in the 

60 design anywhere where the internal data inputs were to be 
coupled to separate data objects outside of the hierarchy. 

At the parent level, equality operators 734 and 738 are 
provided to respectively couple the data object 712 to the 
input ports 730 and 736 of the hierarchical operator 726. 

65 Equality operators 734 and 738 respectively equate the value 
in the result data object 712 of the box operator 710 to the 
input data objects 730A and 736A of 10 ports 730 and 736. 
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Thus, the result of the box operator is passed through the 
equality operator 734 to the 10 port 730, which in turn 
passes the result through equality operator 730B to the data 
object 732 so that it can be operated upon by the top of face 
operator 714. Similarly, this result is also passed through the 5 
equality operator 738 to the 10 port 736, which in turn 
passes the result through equality operator 7363 to the data 
object 740 so that it can be operated upon by the countersunk 
hole operator 716. 

As should be appreciated from the foregoing, by creating 10 
separate IO ports 730 and 736 for data objects 732 and 740 
within the countersunk hole hierarchical operator, the hier- 
archical operator can be copied and replicated in another 
portion of the design, without requiring that those two 
internal data objects be connected to the same data object 15 
outside of the hierarchy. 

The hierarchical operator 726 also includes two output 
ports 7&0 and 742 that export data from the hierarchical 
operator 726. These IO ports respectively include data 
objects 740B and 742B, and equality operators 740A and 
742A that equate those data objects to the result of the 
countersunk hole operator 716 represented by data object 
724. Two IO ports are used to export the result from the 
countersunk hole operator 716 because that operator defines 
the result for the hierarchical operator 726. The first IO port 
740 is dedicated to exporting the result of operator 716 from 
the hierarchy, and will export this result even if the hierar- 
chical operator is modified such that the result of operator 
716 no longer represents the result of the hierarchical 
operator. Conversely, IO port 742 is dedicated to exporting 
the result of the hierarchical operator, so that if changes are 
made internally to the hierarchical operator resulting in 
another internal operator producing the result of the hierar- 
chical operator, IO port 742 will be modified to export the 
new result of the hierarchical operator, and will not export 
the result of operator 716. 

A simple example illustrates the benefit in providing a 
separate result IO port for a hierarchical operator. The 
example shown in FIGS. 17-18 illustrates a very simple 
dependency graph, and it should be understood that a 
significantly more complicated graph can be developed. For 
example, the result of the countersunk hole hierarchical 
operator 726 may be an input to another operator, such as the 
operator 19 shown in FIG. 2 which would calculate the 
weight of the box having the countersunk hole. As stated 
above, hierarchical operators can be modified by the user. 
For example, the user may initially define the countersunk 
hole hierarchical operator 726 in the manner shown in FIG. 
19, and seek to calculate the weight of the box having a 
countersunk hole that is output from operator 716 (FIG. 18) 
and represented by data object 724. However, the user may 
later modify the countersunk hole hierarchical operator, for 
example by creating a second countersunk hole in the box. 
This change could be made by using the result of operator 
716, represented by data object 724, as an input to a new 
series of operators similar to operators 714-716 to create a 
box having two countersunk boles. If the countersunk hole 
hierarchical operator 726 were modified in this manner, the 
result of the hierarchical operator to be exported to the 
calculate weight operator would no longer be the result of 
operator 716, but rather, would be the result of the subse- 
quent operator mat provides the second countersunk hole. 
Thus, the result IO port 742 could be modified to export the 
result of that second countersunk hole operator as the result 
of the hierarchical operator. However, other portions of the 
design may require that the result of the first countersunk 
hole operator 716 also be exported. Therefore, by creating a 
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separate result IO port, it is ensured that the result of the 
hierarchical operator is always exported, even as changes 
within the hierarchical operator are made, while simulta- 
neously ensuring that the results of intermediate operators 
within the hierarchical operator that are used by other 
portions of the design outside of the hierarchical boundary 
are also exported. 

In the illustrative example shown in FIG. 18, the operators 
provided in the input and outputs ports are all equality 
operators. However, it should be understood that different 
types of operators can be employed, particularly in the 
output ports. This provides additional flexibility in the 
manner in which the result of a hierarchical operator can be 
provided to operators in the dependency graph that lie 
outside the hierarchy. 

Referring to the example of FIG. 16, the output of the 
countersunk hole hierarchical operator is an application 
entity defining a box having a countersunk hole. Some 
operators in the dependency graph outside of the hierarchy 
20 may wish to receive only a portion of the information 
relating to the box having the countersunk hole. For 
example, another operator may require only one face of the 
box. In that case, the operator 742A for the result port of the 
hierarchical operator can be modified so that it does not 
25 merely pass the box having the countersunk hole out of the 
hierarchy, but rather, determines the desired face for the box 
and sources that to the operator outside of the hierarchy. 

To provide the above-described capability, the output 
ports of the hierarchical operators include an operator and a 
30 data object in the illustrative embodiment of the invention 
disclosed in FIG. 18. However, it should be understood that 
an output port can alternatively be formed merely from a 
data object representing the result to be exported (e.g., the 
data object 724 in FIG. 18), and need not include an operator 
35 and an additional data object. However, such an implemen- 
tation would not provide the above-described beneficial 
capabilities. 

The operators in the input ports for hierarchical operators 
are typically equality operators. Therefore, each inputs port 
40 can alternatively be implemented as simply a data object 
(e.g., data object 732 in FIG. 18) that receives the data input 
to be imported into the hierarchical operator. However, in 
the embodiment of the invention illustrated in FIG. 18, the 
input ports are also implemented with an additional data 
45 object and an operator so that the input and output ports are 
defined in a consistent manner. 

As stated above, when a hierarchical operator is copied 
and replicated within a design, each instance of the hierar- 
chical operator may have a different set of input and output 
50 ports, depending upon its environment in the dependency 
graph. The different sets of IO ports can port different 
internal data objects to and from the different instances of 
the hierarchical operator. In addition, two instances of a 
hierarchical operator that export the same data object may 
55 include different operators in their respective output ports. 
For example, one instance of the countersunk hole hierar- 
chical operator shown in FIG. 18 may include an equality 
operator in its result output port 742, such that the applica- 
tion entity representing the box having the countersunk hole 
60 would be output, whereas another instance could include an 
operator as discussed above that outputs only a single face 
of the box. 

The determination of which data objects within a hierar- 
chical operator are to be imported and exported through the 
65 creation of IO ports and an updating of the IO_OP list of 
ports is made by the graph manager 75 (FIG. 5). This 
determination is based upon which data objects are coo- 
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nected to portions of the graph outside of the hierarchical hierarchy is closed. By tracking the commit hierarchy corn- 
boundary. For data objects scoped outside of a hierarchical mands to the open hierarchy commands, a number of nested 
operator, their relationships to other graph elements are hierarchical operators can be created. The graph manager 
defined by a parent function that includes the hierarchical maintains a frst-in last-out stack of currently open hierar- 
operator. As stated above, hierarchical operators can be 5 chical operators. Thus, when a commit hierarchy or abort 
nested through a number of levels. Therefore, the outputs of hierarchy command is received, the most recently opened 
a hierarchical operator may be connected to other graph hierarchical operator added to the stack is respectively 
elements within a larger hierarchical operator. When this is committed to the design as a complete hierarchical operator, 
the case, the larger hierarchical operator serves as the parent or is removed from the design so that the graph elements 
function that defines the relationship of the data objects 10 added subsequent to the opening of mat hierarchy are simply 
scoped out of the lower level hierarchical operator to other added to the design as if the most recently opened hierar- 
graph elements within the larger hierarchical operator. If the chical operator were never opened. If another hierarchical 
outputs scoped from the hierarchical operator are at the . operator is currently open on the stack when an abort 
highest level of the design, such that they do not form a command is received, the graph elements will simply be 
portion of another hierarchical operator, then the root of the 15 added to the graph as part of that hierarchical operator when 
design serves as the parent function that defines the manner it is subsequently committed to the graph, 
in which the data objects scoped from the hierarchical Whenever a design session is begun, a top level hierar- 
operator are connected to other graph elements. chical operator is automatically created and pushed onto the 
As stated above, the IO_OP and the IO ports for each graph manager stack. This top level hierarchical operator 
hierarchical operator are created and managed by the graph 20 represents the root for the entire design that will be created 
manager 75 (FIG. 5). The IO_OPis implemented as a graph during a design session. As stated above, this design root 
entity, and includes a pointer to its corresponding hierarchi- serves as the parent function that defines the relationships 
cal operator in the dependency graph. The hierarchical between the next highest level of hierarchical operators and 
operator in the graph similarly includes a pointer to its any non-hierarchical operators at the design level, 
corresponding IO_OP. The IO_OP includes the list of 10 25 The abort command provides the user with the flexibility 
ports representing the data objects that are imported to and to change his mind with respect to a goal oriented activity, 
exported from the hierarchical operator. Thus, the IO OP Similarly, this command can also be employed by the 
serves as a collection of relations for the hierarchical opera- software system on which the associativity subsystem of the 
tor. The 10 ports themselves define those relations. present invention is installed. When the software system 
1. Hierarchical AAPIs 30 seeks to implement the hierarchical operator capability of 
The associativity subsystem of the present invention the present invention, the AAPIs that correspond to propri- 
provides several AAPIs to support the use of hierarchical etary APIs that are generally used in a hierarchical fashion 
operators. As discussed above, the hierarchical operators can will call the open hierarchical operator command anytime 
be employed in one of two ways. First, a user can create his one of those proprietary commands is entered by the user, 
own hierarchical operators in any manner desired. In order 35 However, the user may terminate a hierarchical command 
to do so, the user simply employs the supporting AAPIs prior to completion. When this occurs, the software system 
described below to create hierarchical operators. Second, the can employ the abort command to abort the creation of the 
software system on which the associativity subsystem of the hierarchical operator opened for the proprietary command, 
present invention is installed can also call the supporting 2. Committing An Operator 

AAPIs to implement hierarchical operators around com- 40 In addition to hierarchies committed to the design, each 

mands that include one or more subcommands as described operator created in response to a user command is also 

below. committed to the design if it executes correctly. The graph 

Three basic AAPIs are provided to support hierarchical manager performs the following three basic steps when 
or^mtors. A nrst opens a Merarchical operator. When at least committing an operator to the design; (1) processing the 
one hierarchical operator has been opened, all dependency 45 operator; (2) processing the output of the operator, and (3) 
graph elements added to the design are included within the processing the inputs of the operator. These steps are rep- 
most recently opened hierarchical operator until that hier- resented by the flowcharts of FIGS. 19a-19d 
archy is committed to the design. Once a hierarchy is When an operator is committed to the design, the graph 
committed, it is closed and new dependency graph elements manager initially executes a commit operator routine repre- 
are not added to that hierarchy, unless the hierarchy is so sented by the flowchart of FIG. 19a. In step 610, the method 
re-opened. The second AAPI that supports hierarchical determines whether there is an operator to be committed to 
operators is the commit hierarchy command, which commits the design, and when mere is, the method proceeds to step 
the most recently opened hierarchy to the design in the 612 wherein a toenrrination is made as to whether there is 
manner describe above. Finally, an abort hierarchy AAPI is a target operator for the operator to be committed to. These 
also provided to abort the creation of the most recently 55 two steps are error checkers. As stated above, whenever a 
opened hierarchical operator. When the abort command is design session is begun, a hierarchical operator that repre- 
received, the most recently opened hierarchy will not be sents the root of the design is automatically opened and 
created, and each of the graph elements added subsequent to pushed onto the graph manager stack. Thus, if the commit 
the opening of the most recently opened hierarchy will be operator routine is called and there is no operator to be 
added to the design simply as a group of graph elements 60 committed, or if mere is no target operator to which the 
without being grouped in a hierarchical fashion. operator can be committed, an error condition occurs and the 

As stated above, the present invention enables hierarchi- method proceeds to step 614 wherein it provides an error 

cal operators to be nested. Thus, following the opening of a message to the user and then terminates, 

hierarchical operator, one or more additional hierarchical When no error condition is encountered, the method 

operators can be opened before closing the previously- 65 proceeds to step 616 wherein the operator to be committed 

opened hierarchical operator. Thus, each time a commit to the design is popped (i.e., read) from the graph manager 

hierarchy command is received, the most recently opened stack. In step 618, the next operator on the stack is identified 



12/10/2003, EAST version: 1.4.1 



5,689,711 

35 36 

as the target operator to which the operator popped from the When a hierarchy was destroyed, the method proceeds to 

stack in step 616 is to be committed. Finally, in step 620, the step 626, wherein the commit operator routine of FIG. 19a 

routine calls the add operator routine represented in FIG. is called for each operator that was in the hierarchy 

19b to operate upon the target operator, with the operator destroyed in step 624. Since those operators were pushed 

popped from the stack in step 616 being provided as an 5 onto the graph manager stack during step 622, they can be 

argument to the routine. popped off the stack when processed by the commit operator 

In the illustrative embodiment shown in FIGS. 19a and routine in step 616 (FIG. 19a) in the manner described 

19b, the committing of an operator to the design is con- above. In this manner, whenever a hierarchical operator is 

trolled in part by the target hierarchical operator to which it destroyed, the execution of step 626 ensures that each of the 

is committed. As stated above, each operator added to the io lower level operators within the destroyed hierarchy are 

design will either be added as part of the root of the design committed to the design. 

itself, or as part of a lower level hierarchical operator in the When it is determined at step 624 that no hierarchical 

design. Thus, when an operator is added to the design, the operator was destroyed in step 622, the add operator routine 

add operator routine receives the operator to be committed proceeds to step 628, wherein it calls the input processing 

as an argument, and is called in connection with the hier- 15 routine of FIG. 19c. The purpose of the input processing 

archical operator to which that operator is to be committed routine is to process hierarchical operators by scoping their 

In step 622, the add operator routine processes the opera- inputs through levels of hierarchy in the dependency graph, 

tor passed to it as an argument to ensure that no excess As discussed above, this is accomplished by creating an IO 

hierarchy is created in the dependency graph. As discussed port for each input that crosses the hierarchical boundary, 

above, any software system on which the associativity 20 and creating an equality operator outside the hierarchy that 

subsystem of the present invention is installed may take connects the IO port to the data object in the parent level of 

advantage of the hierarchical capability of the present inven- the graph that provides its input Thus, the input processing 

tion. Thus, for commands in the software system that will routine for an operator committed to the dependency graph 

typically be used in a hierarchical fashion, the software creates any input ports needed for the hierarchical operator 

system may have the corresponding AAPI for the command 25 that includes the newly committed operator, 

open up a new hierarchy whenever the command is received. The input processing routine initially selects a first input 

For example, the countersunk hole command described of the committed operator for processing in step 750. In step 

above in connection with FIGS. 15-18 is typically executed 752, a determination is made as to whether the source data 

with subcommands to identify the face of the solid on which object for the selected input is in the same hierarchy, i.e., 

the countersunk hole is to be applied Thus, when the 30 whether the source of the data object is in the target 

countersunk hole command is executed, a hierarchy may be hierarchy to which the operator is being committed. When 

opened in anticipation of receiving a number of subcom- the source data object is in the same hierarchy, the selected 

raands generally used in connection with that command. input need not be scoped out of the hierarchy, and therefore, 

However, if the user does not execute the expected the input need not be further processed Therefore, the 

subcommands, an unnecessary hierarchy could potentially 35 method proceeds directly to step 788, wherein a determina- 

be created. For example, if the user simply executed the tion is made as to whether any additional inputs remain to be 

counter sunk hole command without subcommands to define processed When additional inputs remain, the method 

the face of the solid, the hierarchy created for the counter- returns to step 758 to select another input for processing, 

sunk hole command would be created solely around the When it is tetermined that no inputs remain to be processed 

countersunk hole operator 716. This hierarchy is unneces- 40 for the committed operator, the method terminates, 

sary because it includes a single operator. When it is determined at step 752 that the input selected 

The operator processing function performed during step for processing in step 750 and its source data object are not 

622 of the add operator routine identifies and removes such in the same hierarchy, the method proceeds to step 754, 

unnecessary hierarchies. When a hierarchy is removed, each wherein a new data object is created for the selected input 

of the operators that had been previously identified as 45 within the target hierarchical operator to which the operator 

belonging to the removed hierarchy are pushed onto the is being committed An example of such a data object is data 

graph manager stack in step 622, so that they will be object 732 in FIG. 18. By creating the new data object, it is 

committed to the graph during step 616 of the commit ensured mat me relation mat connects me source data object 

operator routine discussed below when that routine is called to the selected input of the operator being cornmitted does 

during step 626 of the add operator routine. 50 not cross the hierarchical boundary of the target operator. 

In one embodiment of the present invention, a default In step 756, a hierarchy parent list is generated for the 

option for the processing function of step 622 is to remove committed operator. The hierarchy parent list is analogous to . 

any hierarchy created around a single operator. Thus, in the an ancestral tree for the committed operator, and identifies 

example described above, the hierarchy created solely each of the hierarchies to which the committed operator 

around the operator 716 would be removed However, the 55 belongs, as well as their hierarchical relationship. The hier- 

software system on which the associativity subsystem of the archical parent list is used by the routine in a manner 

present invention is installed is provided with the capability described below to determine at which hierarchical level an 

of overriding this default, and may choose to create a equality operator (e.g., operators 734 and 738 in FIG. 18) 

hierarchy around even a single operator. In addition, the should be provided to connect me selected input to its source 

default can be modified to establish any minimum number of 60 data object 

operators that must be included to form a valid hierarchical The method next proceeds to step 758 wherein the opera- 
operator. In this manner, the software system is provided tor that generates the source data object is identified, and in 
with the flexibility of controlling the manner in which step 760 the hierarchy parent list for that operator is gener- 
hierarchies are created ated. At step 762, the parent list for the committed operator 
After the operator is processed, the add operator routine 65 is compared against the parent list for the source operator to 
proceeds to step 624, wherein a detenmnation is made as to identify the lowest ancestral hierarchy common to both. This 
whether an operator hierarchy was destroyed during 622. hierarchical level is designated as the target parent level for 
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creation of an equality operator between the source data other end is connected to the data object representing the 
object and the selected input. Other hierarchical levels that source at the target level. When the source operator is 
include the two will not require a scoping out of the selected hierarchical, this connection is made to the 10 port created 
input, because the connection between the selected input and for the source data object at the level immediately below the 

its source data object will be internal to a hierarchical 5 target 

operator at the target level. However, the routine scopes the Afta: the equality operator is created in step 784, the 

selected input out of any hierarchical operator at the target method proceeds to step 786, wherein the equality operator 

level and below to ensure that the relation between the is committed to the design of the target leveL The method 

selected input and its source data object does not cross a then proceeds to step 788 (FIG. 19c), wherein a determina- 

hierarchical boundary. 10 tion is made as to whether any inputs of the committed 

At step 764, the method selects for processing the lowest operator remain to be processed. When it is determined that 

hierarchical level far the committed operator, ie., the hier- additional inputs remain, the method returns to step 750, 

archical operator to which the committed operator is being wherein a next input is selected for processing. In this 

committed. In step 766, a determination is made as to manner, the method proceeds to scope out each of the inputs 

whether the currently processed hierarchical level is the is of the conunitted operator until it is determined at step 788 

target leveL When the currently processed level is not the that all of the inputs have been processed, at which point the 

target the method proceeds to step 768, wherein an 10 port method terminates. 

is created to export the selected input from the hierarchical After the input processing routine returns, the add opera- 
operator at the currently processed level. Next, the method tor routine proceeds to step 630 (FIG. 196) to process the 
proceeds to step 770 wherein it goes to the next hierarchical 20 result of the operator being committed The processing of 
level for processing, and then returns to step 766. In this the result is performed to ensure that if the operator is a 
manner, the method proceeds through steps 766-770 to hierarchical operator, its result 10 port accurately reflects the 
create an 10 port for the selected input of the committed output of the operator. For example, as discussed above in 
operator at every hierarchical level below the target level, connection with the dependency graph of FIG. 18, the 
until it is determined at step 766 that the target level has been 25 hierarchical operator 726 produces a result that is an appli- 
reached. cation entity representing a box having a countersunk hole. 

When it is determined at step 766 that the currently However, modifications within the countersunk hole hierar- 

processed level is the target level, the method does not chical operator can change the result of the hierarchical 

proceed to step 768 to create an IO port at this level, because operator, for example, by adding additional countersunk 

as discussed above, the target level includes both the 30 holes. Each hierarchical cperatcrrnamtains a result operator 

selected input and the source data object, and therefore, does pointer that points to its internal operator that, when 

not require scoping out of the input Rather, when the target executed, yields the result of the entire hierarchical operator, 

level is detected in step 766, the method proceeds to step 774 This operator is simply the equality operator in the result IO 

(FIG. 19d) y wherein processing of the source operator port (e.g., operator 742A in FIG. 18) that points to the data 

begins. 35 object that is the result of the hierarchical operator. When a 

The method performs several steps analogous to those new operator is added to the hierarchy and its result becomes 

described above to scope out the result data object, when the result of the hierarchical operator, the processing of the 

provided from a hierarchical operator, from its hierarchy for hierarchical operator result ensures that the input relation of 

connection to the selected input of the committed operator. the result operator is adjusted to point to the result of the 

Specifically, in step 774, the method selects the lowest 40 newly added operator. 

hierarchical level of the source operator for processing, and Different hierarchical operators may behave differently 

then proceeds to step 776 wherein a determination is made with respect to the manner in which their outputs are 

as to whether the currently processed hierarchical level is the processed to define the result of the hierarchical operator, 

target level. When the source operator is not hierarchical, the For example, for many hierarchical operators, the last (i.e., 

its lowest level will be the target level. When it determined 45 the one on the right-hand edge of the dependency graph) 

at step 776 that the currently processed hierarchical level is operatormay define the result of the hierarchy. However, for 

not the target level, the method proceeds to step 778, some hierarchical operators, this will not hold true. For 

wherein an IO port is created to export the result data object example, for a hierarchical operator that produces a 

from the hierarchical operator at the currently processed worlcpiece, such as the box output from the countersunk hole 

level. Next, the method proceeds to step 780 wherein it goes 50 hierarchical operator 726 of FIG. 17, the result of the 

to the next hierarchical level for processing, and then returns hierarchical operator will always be the workpiccc. Thus, 

to step 776. In this manner, the method proceeds through even if other operators are added to the hierarchical operator 

steps 776-780 to create an IO port for the source data object and operate upon the worlqpiece (e.g., calculate weight of 

at the target level and each level below, until it is determined box), the workpiece will be result of the hierarchical opera- 

at step 776 that the target level has been reached. 55 tor. In one embodiment of the invention, a default condition 

When it is determined at step 776 that the currently is instituted which causes the result operator of a hierarchi- 

processed level is the target level, the method does not cal operator to point to the data object that is the result of the 

proceed to step 778 to create an IO port at this level, because operator most recently committed to the hierarchy, 

as discussed above, the target level includes both the However, this default can be overridden by the user or the 

selected input and the source data object, and therefore, does 60 software system in the creation of any particular hierarchical 

not require scoping out of the source data object operator. 

When the target level is detected in step 776, the method As described above, the capability provided to the soft- 
proceeds to step 784, wherein an equality operator (e.g., ware system to group commands in a hierarchical fashion 
EQOPs 734 and 738 in FIG. 18) is created at the target level. may be used in connection with commands that are grouped 
One end of the equality operator is connected to the IO port 65 together with a series of subcommands. For example, the 
created for the selected input of the conunitted operator at countersunk hole command described above is typically 
the hierarchical level immediately below the target, and the executed with a plurality of subcommands to define for 
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example the face of the solid being operated upon. The user AAFI wrapped around each proprietary API in the software 
interface typically does not execute the higher level- system, as well as the three above-described AAPIs that are 
command until its associated subcommands are received used to support hierarchical operators. When the user takes 
from the user. Thus, the commit operator routine of the some action in the visual programming environment, the 
present invention will not be called to commit an operator 5 interpreter 52 parses the exra'essions received from the 
corresponding to a high level command (e.g., the counter- visual prograrwning environment 50, and calls the corre- 
sunk hole operator 716) until all of its subcommands have sponding AAPIs with properly formatted arguments to 
been received. Therefore, when a high level command is execute the user's design action in the dependency graph, 
initially received from the user, a new hierarchy may be The interpreter is integrated into the interactive visual pro- 
opened, and the hierarchy is not committed until each of the 10 gramming environment so that the expressions parsed by the 
subcommands has been executed. In this manner, the com- interpreter can be received as a result of the user typing in 
mand can be grouped with its subcommands in a hierarchi- commands on a system keyboard, or through any other input 
cal operator. mechanism. 

As should be appreciated from the foregoing, the above- A software routine executed by the interpreter whenever 

described ability of the software system to define a group of is an expression is received from its text window or the visual 

subcommands associated with a high level command in a prograniming environment 50 is illustrated in the flowchart 

hierarchical block cannot be employed to group together of FIG. 20. Id step 900, the interpreter parses the received 

more than one high level command, since an operator will expression to determine the name of the AAPI referenced in 

be coinmitted to the design for each high level command, the expression. The method then proceeds to step 901, 

thereby closing any hierarchy that may have been opened 20 wherein the interpreter stack is cleared. The interpreter stack 

specifically for that command. However, as described above, is used in a manner discussed below to store a result value 

this capability is provided to the user so that he can specify during recursive execution of the interpreter routine for 

hierarchical groups in any manner desired, including hier- feature commands that receive arguments through the 

archies that include multiple high level commands. execution of subcommands. Thus, the result value stored on 

VTT Interactive Dependency Manipulation 25 the interpreter stack represents the result of an AAPI 

As discussed above, in one embodiment of the present executed in connection with a subcommand, and is used to 

invention, a capability is provided to allow a user to interact provide an argument in calling an AAPI for the feature 

with the dependency representation of a design in order to command for which (he recursire routine was initially called, 

create a design or make modifications to an existing design. The stack is only used within a single recursive cycle of 

It should be appreciated that in some instances, it will be 30 executions for the interpreter routine. However, when a 

faster and easier for a user to interact with this graphical recursire cycle is completed, the routine may return without 

representation of the design. clearing the stack Therefore, the stack is cleared in step 901 

As shown in FIG. 3, when the associativity subsystem of at the beginning of the routine so that if the routine is called 

the present invention is installed on a software system, the consecutively for two commands that do not employ a 

system is provided with an interpreter 52. The interpreter 52 35 subcoiumand and therefore doe not recursively execute the 

includes a text window that can be displayed on a display interpreter routine, no argument will be detected on the stack 

screen of the software system, and which enables the inter- in step 910 discussed below. 

preter to receive textual AAPI expressions from the user. After the stack is cleared, the method proceeds to step 902 

The interpreter 52 translates the textual AAPI expressions wherein the arguments for the AAPI parsed in step 900 are 

and calls corresponding AAPIs 42 on the system to take 40 identified. The arguments are identified by accessing the 

design actions specified by the textual AAPI expressions. hash table 73 discussed above in connection with FIG. 5, 

Thus, the text window of the interpreter can be used to create which includes an entry for each AAPI that identifies its 

or edit a dependency graph in accordance with the present arguments and the order in which those arguments are to be 

invention using textual AAPI expressions. presented when the AAPI is called for execution. 

As stated above in connection with the discussion of FIG. 45 In step 904, the method selects the argument identified in 

3, when the embodiment of the present invention is step 902 as being the first in the ordered list of arguments to 

employed that allows the dependency graph to be edited be presented when calling the AAPI, and the method pro- 

graphically, the system is also provided with a visual pro- ceeds to step 906, wherein a determination is made as to 

gramming environment 50 that is used in graphically editing whether a subcommand is to be executed to provide the data 

the dependency graph. The capability of the present inven- 50 value for the selected argument This detennination is made 

tion to support graphical editing of the dependency graph is by parsing the list of arguments. If the argument includes the 

not limited to any particular visual programming name of an AAPI, then the argument will be provided by a 

environment, and the present invention can be used with any subcommand. When it is determined at step 906 that a 

type of visual prograrnming environment, of which several subcommand is to be executed, the method proceeds to step 

are commercially available. 55 908, wherein the interpreter routine is re-called using the 

As shown in FIG. 3, the visual rrogranmuflg environment name of the AAFI that will produce the value for the 

50 is coupled to the interpreter 52 that is in turn coupled to argument 

the associative APIs 42 of the system. The visual program- As is discussed below in connection with steps 926-928, 

ruing environment translates actions taken by the user in a when the interpreter routine is called to process an AAPI, the 

visual environment into expressions that are compatible with 60 last two steps of the routine execute the AAFI to perform the 

the interpreter. Thus, the interpreter acts a parser that trans- design action specified in the expression received from the 

lates between the language of the visual rffograrrarjing interpreter text window or the visual programming 

environment 50 and the associative APIs 42 of the software environment, and then push the result of this execution on 

system. The interpreter 52 establishes lexicons that define the interpreter stack. The interpreter stack is a first-in 

valid words to be parsed, as well as the supported gram- 65 last-out stack that stores the results of AAPIs executed 

matical rules for presenting the lexicons. The AAPIs 42 of during recursire calls of the interpreter routine in response to 

the system with which the interpreter operates include an expressions received from the text window and the visual 
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programming environment Thus, when the interpreter rou- AAPI that generates the box could be displayed using the 
tine returns from a call in step 908 that caused it to process visual programming environment Alternatively, the inter- 
a subcommand identified in step 906, the result of the AAPI preter text window can be used to textually display the 
executed to implement the subcommand is stored on the AAPIs that generate the selected portion of the design, such 
interpreter stack. 5 that the display screen could be provided with a textual 
When the interpreter routine returns from processing a rer^esentation of the command "CV_JNSERT_BOX(l,w, 
subcommand in step 90S, or when it is determined at step h } center) n , along with its accompanying data arguments. 
906 that no subcommand need be executed for the selected Once the textual AAPI or dependency graph representa- 
argument, the method proceeds to step 910, wherein a tion selected by the user is displayed, the representation of 
detennination is made as to whether an argument is stored 10 the portion of the design can be modified using the inter- 
on the interpreter stack. As stated above, the stack is cleared preter text window or the visual programming environment 
in step 901 when the interpreter routine begins. Therefore, 50, Graphically editing the dependency graph can involve 
when an argument is stored on the interpreter stack, it either redefining a data input to an operator, or replacing an 
indicates that the argument was provided by an iteration of operator. Similarly, editing an AAPI textually can involve 
the routine called to process a subcommand, and therefore, 15 redefining one of its arguments, or replacing the AAPI with 
the method proceeds to step 912, wherein the argument another. 

value is popped from the interpreter stack Conversely, when When the user selects an application entity representing a 

it is determined at step 910 that there is no argument on the portion of the design to be edited, an editing routine 

stack, the method proceeds to step 914, wherein the value for executed by the graph manager 75 (FIG. 5) is called to 

the selected argument is read from the expression provided 20 handle the editing operation. The editing routine is repre- 

from the interpreter text window or the visual programming sented in the flowchart of FIG. 21. Initially, in step 930, the 

environment 50. routine identifies the application entity selected for editing 

After the value for the argument is popped from the stack by the user. Thereafter, in step 932, the routine finds the 

in step 912 or read from the text window or visual program- AAPI that corresponds to the selected application object 

ming environment in step 914, the method proceeds to step 25 when textual editing is being performed, and finds the 

916, wherein the value is assigned to the argument selected corresponding operator in the dependency graph when 

for processing. The method then proceeds to step 918, graphical editing is being performed, 

wherein a determination is made as to whether the argument In step 934, the AAPI or operator identified in step 932 is 

value is of the type expected far the AAPI identified in step presented to the user for editing. When an edit operation is 

900. When the argument value is not of the type expected, 30 received through the interpreter from its text window or the 

the method proceeds to step 920 wherein an error message visual programming environment, the routine proceeds to 

is provided to the user, and the method terminates. In this step 936 wherein a determination is made during textual 

manner, the user is provided with an opportunity to redefine editing as to whether an AAH is being edited, and during 

the argument value into an acceptable type. graphical editing as to whether an operator is being edited. 

When it is determined at step 918 that the value assigned 35 When it is d^rmined that either an AAPI or a graph 

to the selected argument is of the correct type, the method operator is being edited, the routine proceeds to step 938, 

proceeds to step 922, wherein a determination is made as to wherein the interpreter routine of FIG. 20 is called to operate 

whether any more arguments remain to be processed for the on the new AAPI or operator. As discussed above, the 

AAPL When it is determined that additional arguments interpreter routine collects all of the argument values for the 

remain, the method proceeds to step 924, wherein the next 40 new AAPI and calls the AAPI with its ordered list of 

argument in the list of ordered arguments for the AAPI is arguments to perform the design action specified by the 

selected for processing, and the method returns to step 906. user's edit When the interpreter routine returns, the method 

In this manner, the method proceeds to process each of the proceeds to step 940, wherein the replace operator routine 

arguments for the AAH until a determination is made at step described below in connection with FIG. 23 is called, and 

922 that all of the arguments have been processed. 45 then terminates. When it is determined at step 936 that the 

Once all of the arguments have been processed, the user has not edited either an AAPI or a graph operator, the 

method proceeds to step 926, wherein the AAPI parsed in method proceeds to step 942, wherein a determination is 

step 900 is called, with the argument values collected by the made as to whether the user has edited an argument. If no 

routine in their correct ordered positions. In this manner, the argument was edited, the method simply terminates, 

interpreter routine ensures that the design action required by 50 However, when it is determined at step 942 that the user has 

the expression received from the interpreter text window or edited an argument, the routine calls the redefine input 

visual prograrnming environment 50 is taken in the design. routine (FIG. 22) discussed below in step 944, and then 

Finally, in step 928, the result returned from the AAPI is terminates. 

pushed onto the interpreter stack, so that when the inter- The redefine input routine is represented by the flowchart 

preter routine is called for a subcommand for the AAPI in 55 of FIG. 22, which performs a number of steps that are 

step 908, the result can be read from the stack in step 912 in similar to steps performed by the interpreter routine of FIG. 

the manner described above. 20. Initially, in step 946, the routine clears a stack that is 

When a user is creating or editing a design, the present similar to the interpreter stack discussed above. The stack is 

invention provides a capability for the user to identify a cleared initially for the same reasons that the interpreter 

portion of the design, and request that the AAPIs that 60 stack is initially cleared in step 901 of the interpreter routine, 

generate that portion of the design be displayed using the Next, in step 948, the routine selects an edited argument for 

interpreter text window or visual programming environment processing. Thereafter, the routine proceeds through steps 

50. For example, a user modifying a design represented by 949-968, which are virtually identical to steps 906-926 in 

the dependency graph of FIG. 2 could simply point to the the interpreter routine described above in connection with 

display screen representation of the application entity that 65 FIG. 20. Through the execution of these steps, the redefine 

represents the box, and the portion of the dependency graph input routine collects all of the edited argument values for an 

of FIG. 2 that includes the operator 7 corresponding to the AAPI, as well as its other argument values, and then calls the 
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AAH with its ordered list of argument values in step 968 to 
take the design action requested by the user's edits. 
Thereafter, in step 970, the routine calls the replace operator 
routine of FIG. 23 discussed below, and then terminates. 

The replace operator routine that is called by both the 
editing routine of HG. 21, and the redefine input routine of 
FIG. 22, is represented by the flowchart shown in FIG. 23. 
Prior to the replace operator routine being called, either a 
new AAPI will have been executed as a result of a call to the 
interpreter routine in step 938 of the editing routine (FIG. 
21), or an existing AAPI will be rc-executed with new data 
in step 968 of the redefine input routine (FIG. 22). As aresult 
of the execution of the AAPI in either of these instances, 
additional graph elements will be created, including a new 
operator, relations for its inputs, a relation for its output, and 
a new result data object The purpose of the replace operator 
routine is to clean up the dependency graph so that it 
accurately reflects the user's edits to the design. 

Initially, in step 972, a determination is made as to 
whether any graph elements are dependent upon the result 



As discussed above, through the use of a visual program- 
ming environment 50 (FIG. 3), a user of a software system 
having the associativity subsystem of the present invention 
installed thereon is provided with the capability of graphi- 
cally editing the dependency graph representation of the 
design. The visual presentation of the dependency graph can 
take any number of forms. One illustrative example is shown 
in FIGS. 24a-24&, which shows a visual representation of 
the dependency graph of FIGS. 16-17. 

The dependency graph is visually presented on a visual 
environment canvas 990, such as a display screen for the 
software system. Also displayed is a toolbox of AAPIs 990, 
which comprises a list of associative APIs that are available 
for the user to select in creating and editing the dependency 
graph. A representative list of AAPIs is included in the 
15 toolbox 992 of FIGS. 24a-2Ab. The AAPIs in the toolbox 
992 may be represented by icons or other symbols that can 
be activated to add corresponding graph entities to the 



10 



design. 

In FIG. 24a, the hierarchical countersunk hole operator 
data object of the old operator that is to be replaced When 20 726 is displayed, along with its connections to the box 
it is determined that nothing in the dependency graph operator 710. The hierarchical nature of the operator 726 is 
depends on the result of the old operator, the method indicated by double lines defining its boundaries. The data 
proceeds to step 973, wherein the result data object of the old objects in the graph are represented as ports on the operators, 
operator is deleted from the dependency graph, and then to The ports may be color coded, with different colors depict- 
step 984 wherein the old operator is also deleted. In this 25 ing the data type expected or generated by the ports. When 
manner, the dependency graph is updated to reflect the edits adding or modifying an input relation to one of the operator 
made by the user. ports, the system may highlight other valid ports in the 

When it is determined at step 972 that some graph dependency graph that can be connected thereto, 
elements depend upon the result of the old operator, the As stated above, the capability may be provided to the 
method proceeds to step 974, wherein a determination is 30 user to open up hierarchical operators. FIG. 24b represents 



made as to whether the result produced by the new operator 
is of the correct type expected by each of the graph elements 
that depended upon the result of the old operator. When it is 
detennined that the result is not of the correct type, the 
method proceeds to step 976, wherein an error message is 
generated to the user indicating that the new operator cannot 
replace the old operator in the design, and the method 
terminates. 

When the result is of the correct type, the method pro- 
ceeds to step 978, wherein the value stored in the result data 
object for the new operator is placed into the result data 
object for the old operator. This is achieved by simply 
updating the pointer in the result data object for the old 
operator to point to the memory location that stores the result 
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the dependency graph of FIG. 24a, but with the hierarchical 
operator 726 opened up to show the internal operators 
714-716 that comprise it. In this representation, the bound- 
ary of the hierarchical operator is still identified by a pair of 
double dotted lines 994. 

It should be understood that while the user is selecting 
icons or other symbols that represent the AAPIs from the 
toolbox and connecting them up in the visual environment 
canvas, the actual graph entities that form the dependency 
graph are not being formed. However, when the user 
instructs the system to process the visual presentation, the 
interpreter 52 (FIG. 3) receives the expressions from the 
visual programming environment 50 that represent the 
visual presentation, and calls the corresponding AAPIs that 



value for the new operator. The method then proceeds to step 45 actually construct the graph entities to create the dependency 

980, wherein the result relation for the new operator is graph in the manner discussed above, 

switched to be connected to the result data object for the old As discussed above, in the embodiment of the present 

operator, again by simply updating the pointer in the result invention wherein hierarchical operators are provided, the 

relation for the new operator. Thereafter, the method pro- user is provided with the ability to copy a hierarchical 

ceeds to step 982, wherein the result data object far the new 50 operator far use in other instances in the design. The visual 



programming environment of the present invention supports 
this capability. When a hierarchical operator is copied, its 
I0__0P and its IO ports are maintained. Therefore, the 
copying of a hierarchical operator is no different from 
55 inserting a single operator from the toolbox of AAPIs into 
the visual environment canvas. Hie hierarchical operator is 
treated just like other operators, and has a defined set of 
inputs and outputs. Once the hierarchical operator is copied 
and placed Into the visual environment canvas, the user need 
for the new operator can be hooked up in the dependency 60 only hook up its IO ports to the desired connections in the 
graph, rather than employing the result data object of the old graph. When a hierarchical operator is copied, the values for 
operator and updating its value. However, the illustrative its internal data objects are also copied so that the user need 
implementation shown in FIG. 23 is advantageous in that the only define the manner in which the IO ports of the hierar- 
data object for the old operator already has previously- chical operator are to be connected, 
connected relations to all of the graph elements that are 65 XTJI. Computer Program Generation 
dependent upon it, and therefore, these connections need not Once a user has completed an interactive design session 
be remade. with the software system, the present invention will have 



operator is deleted. Finally, in step 984, the method deletes 
the old operator, and then terminates. 

As should be appreciated from the foregoing, the replace 
operator routine of FIG. 23 replaces the old operator with the 
newly executed operator and makes all the necessary con- 
nections in the dependency graph to affect the change to the 
design required by the user's edits. It should be understood 
that this routine can alternatively be implemented in a 
number of different ways. For example, the result data object 
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created a dependency graph, such as- the illustrative example 
shown in FIG. 2, that represents the structural dependency of 
the resulting design. The present invention further provides 
a program generation tool that operates on the dependency 
graph to generate a computer program in a standard 
language, such as C++, which when executed will generate 
the dependency graph and the design that it represents. As 
discussed above, the computer program can be edited by the 
user and passed back into the system to generate a modified 
design. 

A flowchart describing the program generation tool is 
shown in FIGS. 13a-13e. Initially, in step 101, each of the 
leaf data objects in the dependency graph is marked as being 
out of synch. The leaf data objects are those in the graph that 
are not fed by an operator, ie,, a leaf data object is not the 
result of an operator. Once the leaf objects have been so 
marked, the method proceeds to step 103, wherein the 
symbolic pass routine of FIG. 8 is called. Each of the leaf 
objects is marked as out of synch so that all will be processed 
by the symbolic pass. As discussed above, the symbolic pass 
routine interrogates the graph to form a list of operators to 
be evaluated, as well as the order in which the list should be 
evaluated. The operators in the list include directed 
operators, or constraint sets of non-directed operators. As 
discussed above in connection with FIG. 8, the list of 
operators is stored on the graph manager stack in the order 
in which the operators are to be executed. Thus, by calling 
the symbolic pass and then processing operators in the order 
specified on the graph manager stack, the program genera- 
tion code generates a program that calls the corresponding 
AAFIs in the same order. 

When the symbolic pass returns, the method proceeds to 
step 105 wherein the next operator in the evaluation order 
stored on the graph manager stack is selected for processing, 
which will be the first operator during the first pass through 
step 105. Thereafter, the method proceeds to step 107, 
wherein a determination is made as to whether the selected 
operator is a constraint set, and when it is, the method 
proceeds to step 109 wherein a single non-directed operator 
from the constraint set is selected for processing. 

After selecting a non-directed operator in step 109, or 
when it is determined at step 107 that the operator selected 
in step 105 is a single directed operator, the method proceeds 
to step 111, wherein the hierarchical file preparation routine 
of FIG. 13d is called in connection with the hierarchical 
operator that is the parent to the directed operator selected 
for processing in step 105, or the non-directed operator 
selected in step 109. As stated above, each operator in the 
dependency graph belongs to at least one parent hierarchical 
operator, with the highest hierarchical operator denning the 
root for the design. The parent hierarchy for each operator is 
stored in a pointer in the graph entity that defines the 
operator, and therefore, can be determined by die program 
generation method simply by querying this graph entity. 

When the hierarchical file preparation routine is called for 
a hierarchical operator, it initially determines at step 165 
whether a file has been opened for the hierarchical operator. 
Hierarchical operators are represented in the code generated 
by the program generation method of the present invention 
by separate functions, with each function being defined in a 
separate file. When it is determined that a file has not yet 
been opened, the method proceeds to step 167, wherein an 
output file is opened for the code that defines the hierarchical 
operator function. 

Once an output file is opened for the hierarchical operator 
being processed, the method proceeds to step 169, wherein 
the pointer for this file is selected as the target, indicating 
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that code subsequently generated is to be placed in this file. 
Thereafter, in step 171, a variable is defined for each IO port 
of the hierarchical operator. The IO ports are identified by 
querying the IO_OP list maintained by the graph entity that 

5 represents the hierarchical operator. Next, in step 175, the 
routine creates the definition for the function that represents 
the hierarchical operator. The function definition includes 
the name of the function, its return type, and the names and 
types of its arguments. The routine uses the variable names 

10 created for the IO ports in step 171 as the arguments for the 
functions. 

After the function is defined, the method proceeds to step 
177, wherein the expression to call the open hierarchy AAPI 
is written out in the file, so that when the code is generated, 

15 a hierarchy will be created for the hierarchical operator 
being processed. Thereafter, the method proceeds to step 
179, wherein a determination is made as to whether a parent 
hierarchy exists for the hierarchical operator being 
processed, and when no such parent hierarchy exists, the 

20 method proceeds to step 185, wherein the file pointer for the 
hierarchical operator is again set as the target for reasons 
discussed below, and the routine terminates. 

When it is determined at step 179 that the hierarchical 
operator being processed has a parent hierarchy, the hierar- 

25 chical file preparation routine is called for the parent hier- 
archy. In this manner, the file preparation routine is recur- 
sively called to process all of the hierarchical operators that 
include the operator initially selected for processing from 
the evaluator stack during step 105 of the program genera- 

30 tion method (FIG. 13a). When the file preparation routine 
returns from processing the parent hierarchical operator, the 
method proceeds to step 183, wherein a call to the hierar- 
chical operator being processed is written into the file for its 
parent hierarchy. In this manner, the function that defines the 

35 parent hierarchical operator will call the function that 
defines the hierarchical operator included within it 

Finally, after the call to the hierarchical operator function 
is written into the file for its parent hierarchical operator in 
step 183, or when it is determined at step 179 that the 

40 hierarchical operator being processed does not include a 
parent, or when it is tetermined at step 165 that a file for the 
hierarchical operator was opened prior to calling the hier- 
archical file preparation routine, the routine proceeds to step 
185, wherein the file pointer for the hierarchical operator 

45 being processed is again set as the target Step 185 is 
included in the file preparation routine because of the 
recursive manner in which it is executed. Specifically, when 
the hierarchical operator for which the routine is initially 
called has at least one parent hierarchical operator, the target 

50 pointer will be set to that parent hierarchical operator in step 
169 of a recursire call to the routine that processes the parent 
hierarchical operator. Before returning to step 113 of the 
program generation method (FIG. 13a), the hierarchical file 
preparation routine again sets the target pointer to .the 

55 hierarchical operator for which it was initially called, so that 
additional code generated during the program generation 
method is written to this file. 

After the hierarchical preparation routine returns, the 
method proceeds to step 113, wherein all of the data objects 

60 attached to the operator selected for processing in step 105 
or step 109 are collected. As discussed above, each operator 
includes a pointer to its relations, which in turn each 
includes a pointer to its corresponding data object. By 
querying the graph entity that represents the operator, the 

65 program generation method can collect a list of all the data 
objects attached thereto. In step 115, the method selects for 
processing one of the data objects attached to the operator 
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being processed. In step 117, the method determines whether operator being processed. This determination is analogous to 

the selected data object has been previously processed, and the one described above in connection with step 127, and 

when it has not, the method proceeds to step 119, wherein a can be made by querying the IO__OP list of 10 ports for the 

variable is declared and named for the selected data object parent hierarchical operator. When it is determined that the 

After a variable is declared for the selected data object in 5 data object selected in step 141 is an 10 port for the parent 

step 119, or when it is determined at step 117 that the hierarchical operator, the method proceeds to step 145, 

selected data object was previously processed, the method wherein the variable name for the 10 port is equated to the 

proceeds to step 121, wherein a determination is made as to variable name declared for the data object in step 119 (FIG. 

whether all of the data objects in the list of attached data 13a). This step is analogous to step 129 (FIG. 13£>) described 

objects formed in step 115 have been processed, and when 10 above, and ensures that the value in the output data object is 

they have not, the method returns to step 115. In this manner, ported, through a corresponding 10 port, out of the function 

the method proceeds through steps 115-121 to ensure that a created for the parent hierarchical operator so that it can be 

variable name is declared for each data object attached to the accessed by the function at the next hierarchical level 

operator being processed. After the variables are equated in step 145, or when it is 

After a variable name has been declared for each of the 15 determined at step 143 that the selected output data object is 

data objects attached to the operator being processed, the not an 10 port of the parent hierarchy, the method proceeds 

method proceeds to step 123 (FIG. 132>), wherein all of the to step 147, wherein a determinatiori is made as to whether 

input data objects included in the list formed in step 115 are any of the output data objects identified in step 139 (FIG. 

identified. For the purpose of identification as an input in 13f>) remains for processing, and when at least one remains 

step 123, the program generation method identifies not only 20 to be processed, the method returns to step 141. In this 

inputs to directed operators, but also every data object manner, the method proceeds to process each of the output 

attached to a non-directed operator. data objects for the selected operator to equate each that is 

After the input data objects are identified, the method an 10 port of its parent hierarchy to a corresponding 10 port 

proceeds to step 125, wherein one of the input data objects variable name. 

is selected for processing. In step 127, a determination is 25 When it is determined at step 147 that no output data 

made as to whether the selected input data object is an 10 objects for the selected operator remain to be processed, the 

input port for the hierarchical operator that is the parent to method proceeds to step 149, wherein a determination is 

the operator being processed. When it is determined that the made as to whether the operator belongs to a constraint set, 

input data object is an 10 port, the method proceeds to step and when it does, whether any additional operators within 

129, wherein the variable name declared for the selected 30 that set remain to be processed. When it is determined at step 

data object in step 119 (FIG. 13a) is equated to the variable 149 that additional operators within the same constraint set 

name declared for the 10 port during step 171 of the remain to be processed, the method returns to step 109 (FIG. 

hierarchical file preparation routine of FIG. 13d. In this 13a), wherein a next operator from the constraint set is 

manner, the value for the selected data object is scoped into selected for processing. In this manner, the method proceeds 

the function created for the parent hierarchy of the operator 35 through steps 109-149 to process each of the operators in a 

being processed. constraint set 

After the variable names are equated in step 129, or when When it is determined at step 149 that the operator being 

it is determined in step 127 that the data object is not an 10 processed does not belong to a constraint set, or that each of 

port for a hierarchy, the method proceeds to step 131, the operators in the constraint set have already been 

wherein a determination is made as to whether any of the 40 processed, the method proceeds to step 151, wherein a 

input data objects identified for the operator in step 123 determination is made as to whether any operators remain on 

remain to be processed, and when at least one remains for the evaluation stack for processing. When it is determined 

processing, the method returns to step 125. In tins manner, that at least one operator remains to be processed, the 

the method proceeds through steps 125-131 to equate the method returns to step 105 (FIG. 13a), wherein the next 

variable names of each of the processed operator's input 45 operator on the stack is selected for processing. In this 

data objects that form an 10 port of the parent hierarchy to manner, the method proceeds through steps 105-151 to 

the variable name for its corresponding 10 port process each of the operators placed on the evaluation stack 

After all of the input data objects have been processed, the resulting from the call to the symbolic pass in step 103. 

method proceeds to step 133, wherein the expression to call When it is determined that no operators remain for 

the AAFI macro that corresponds to the operator being 50 processing, the method proceeds to step 153, wherein the 

processed is written out, along with its corresponding vari- hierarchical closing routine is called, and the method then 

able names. Thereafter, the method proceeds to step 135, terrninates. 

wherein a determination is made as to whether the operator The hierarchical file closing routine is shown in FIG. 13*. 

being processed is directed, and when it is, the method Initially, in step 155, one of the hierarchical operator files 

proceeds to step 137, wherein the single result data object 55 opened in step 167 of the hierarchical file preparation 

for the directed operator is identified. Conversely, when it is routine (FIG. 13d) is selected far processing. Thereafter, the 

determined at step 135 that the operator being processed is file pointer of the selected hierarchical operator file is set as 

non-directed, the method proceeds to step 139 to identify as the target in step 157, so that subsequently generated code is 

an output all of the data objects attached to the non-directed written to this file. 

operators that are variable, i.e., not fixed. 60 After the file pointer of the selected hierarchical operator 

After the output data objects for the operator being is set as the target, the method proceeds to step 159, wherein 

processed are identified in either step 137 or 139, the method the expression to call the commit hierarchy AAPI is written 

proceeds to step 141 (FIG. 13c), wherein one of the output to its file. The routine then proceeds to step 160, wherein the 

data objects is selected for processing. Thereafter, the function return for the hierarchical operator is written out, 

method proceeds to step 143, wherein a o^ennination is 65 including the argument to be returned by the hierarchical 
made as to whether the selected output data object is an 10 operator function. The routine then proceeds to step 161, 
port for the hierarchical operator that is the parent to the wherein the hierarchical operator file selected in step 155 is 
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closed. Finally, the routine proceeds to step 163, wherein a 
determination is made as to whether any more hierarchical 
operator files remain for processing, and when at least one 
remains to be processed, the routine returns to step 155. In 
this manner, the routine proceeds to process each of the open 5 
hierarchical operator files until it is determined at step 163 
that no more open files remain, and then the routine termi- 
nates. 

XTV. Illustrative Hardware System 

FIG. 14 is a block diagram of a hardware system on which 10 
the present invention can be operated. The system includes 
the user interface 37 discussed above, as well as a processor 
600 and an associated memory 601. As discussed above, the 
present invention can be operated on any software system 
made up of functions. Thus, the processor 600 can be any of 15 
various types of processors that is capable of executing 
software functions. The software tools, routines and meth- 
ods of the present invention described herein can each be 
stored in the memory 601 and executed on the processor 600 
to implement the present invention. 20 
XV. Illustrative Method Of Design Iteration 

As should be appreciated from the foregoing, the various 
capabilities of the present invention provide the user with 
tremendous flexibility in generating a design, representing it 
in a dependency graph that can be modified graphically, and 25 
then generating a computer program in a standard language 
that represents the structural dependency of the design, and 
can be executed on the system to generate the design at some 
point in the future. Thus, the high level steps performed by 
a software system on which the associativity subsystem of 30 
the present invention has been installed are shown in the 
flowchart of FIG. 25. 

In step 985, the method receives an input from the user, 
and then proceeds to step 986 to call the corresponding 
AAPI to implement the design action requested by the user. 35 
In step 987, the dependency graph entities for the AAFI arc 
generated, and then the method proceeds to step 988 wherein 
the graph is evaluated. The user may then use the visual 
programming environment to view the dependency graph 
and determine whether the resulting design is acceptable. 40 
When it is determined at step 989 that the result has not been 
accepted by the user, the method proceeds to step 990, 
wherein commands can be received from the visual pro- 
gramming environment to edit the graph. The method then 
proceeds to step 988, wherein the modified graph is evalu- 45 
ated. In this manner, the method proceeds through steps 
988-990 until the user indicates that the resulting design is 
accepted. 

Once the result is accepted, the method proceeds to step 
991 wherein a determination is made as to whether any so 
additional commands are to be received by the user. If more 
commands are received, the method returns to step 986 
wherein those commands are processed. 

When no more commands are received from the user, the 
method proceeds to step 992, wherein a determination is 55 
made as to whether the user desires the generation of the 
standard language computer program that represents the 
structural dependency of the design. When the user does not 
wish to have the computer program generated, the method 
simply terminates. However, when it is determined that the 60 
program should be generated, the method proceeds to step 
993, wherein the program is generated in the manner dis- 
cussed above, and then to step 994 wherein the program is 
compiled and linked to the software system. 
XVI Conclusion 65 

Having thus described various illustrative embodiments 
of the invention, various alterations, modifications and 
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improvements will readily occur to those skilled in the art 
Such alterations, modifications and improvements are 
intended to be within the spirit and scope of the invention. 
Accordingly, the foregoing description and the accompany- 
ing drawings are provided by way of example only, and are 
not intended to be limiting. Hie invention is limited only as 
defined in the following claims and the equivalence thereto. 
What is claimed is: 

1. A method for providing parametric capabilities to a 
software modeling system having a plurality of functions 
and a user interface that responds to receipt of each one of 
a plurality of commands by calling a corresponding one of 
the plurality of functions, the plurality of functions being 
executed during a modeling session to create a model, the 
method including steps of: 

A. providing a wrapper around each of the plurality of 
functions in the software system to create a correspond- 
ing plurality of associative functions, each of the asso- 
ciative functions including a call to its corresponding 
function and further including a capability of creating 
and adding graph entities to a dependency representa- 
tion of the model when its corresponding function is 
executed during the modeling session; and 

B. modifying the user interface so that in response to each 
received command, the associative function that cor- 
responds to the function corresponding to the received 
command is called. 

2. The method of claim 1, wherein at least one of the 
plurality of functions has no inherent parametric capabili- 
ties. 

3. The method of claim 1, wherein the plurality of 
functions includes a first function that operates upon a first 
set of arguments formatted in a first format, and wherein step 
A includes a step of: 

providing a first wrapper around the first function, the first 
wrapper being capable of receiving a second set of 
arguments formatted in a second format that is different 
from the first format, the first wrapper converting the 
second set of arguments to the first set of arguments 
when calling the first function. 

4. The method of claim 1, wherein step A includes 
providing each of the wrappers in an object oriented com- 
puter programming language. 

5. The method of claim 1, wherein steps A and B are 
implemented by a computer executing a computer program 
written in an object oriented language. 

6. Hie method as recited in claim 1, further comprising a 
step of: 

providing a tool that, when a modification is made to the 
model, uses the dependency representation to reevalu- 
ate only the functions used in creating the model that 
correspond to graph entities affected by the modifica- 
tion to the design. 

7. The method of claim 1, further comprising a step of: 
creating a hash table with a table entry for each associa- 
tive function, each table entry identifying a topology of 
the graph entities created and added to the dependency 
representation when the associative function is 
executed. 

8. The method of claim 7, wherein the step of creating a 
hash table includes a step of: 

creating each table entry to identify a number of input data 
arguments required by the associative function, a result 
of the associative function and descriptions of each 
input data argument and the result 

9. The method of claim 1, wherein step A includes a step 
of providing each of the wrappers in a standard computer 
programming language. 
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10. The method of claim 9, wherein step A includes a step 
of providing each of the wrappers in an object oriented 
computer programming language. 

11. The method of claim 1, further including a step of: 
C. creating a single processor function that cooperates 

with each of the associative functions to create and add 
the graph entities to the dependency representation. 

12. The method of claim 11, wherein step C includes a 
step of: 

creating the single processor function to generate a hash 
table with a table entry far each associative function, 
each table entry identifying a topology of the graph 
entities created and added to the dependency represen- 
tation by the single processor function when the asso- 
ciative function is executed. 

13. The method of claim 12, wherein step C further 
includes a step of: 

creating the single processor function to create the depen- 
dency graph by accessing an entry in the hash table, the 
single processor being generic and operating according 
to arguments passed to it when it is called by the 
associative function. 

14. The method of claim 12, wherein step C includes a 
step of: 

creating the single processor function to create each table 
entry to identify a number of input data arguments 
required by the associative function, an output of the 
associative function and descriptions of each input data 
argument and the output. 

15. A software modeling system for creating a model 
during a modeling session, the model being formed from a 
plurality of design entities, the software modeling system 
comprising: 

a processor having a plurality of functions that are 
executed thereon to create the plurality of design enti- 
ties that form the model; 

a user interface that responds to receipt of each one of a 
plurality of commands by calling a corresponding one 
of the plurality of functions; 

a wrapper around each of the plurality of functions that 
creates a corresponding plurality of associative 
functions, each of the associative functions including a 
call to its corresponding function, each of the associa- 
tive functions further including means for creating and 
adding entries to a dependency representation when its 
corresponding function is executed during the model- 
ing session, the dependency representation indicating 
dependencies of the plurality of design entities that 
form the design; and 

means for modifying the user interface so that in response 
to each received command, the associative function 
that corresponds to the function corresponding to the 
received command is called. 55 

16. The software modeling system of claim 15, wherein 
the plurality of functions includes directed and non-directed 
operations and wherein the software modeling system fur- 
ther includes: 

means for creating the dependency representation to ^ 
include design entities created by both the directed and 
non-directed operations. 

17. The software modeling system of claim 15, further 
including: 

means far generating a standard programming language 65 
computer program from the dependency representa- 
tion. 
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18. Hie software modeling system of claim 15, wherein 
the plurality of functions includes directed and non-directed 
operations; 

wherein the creating means includes means for creating 
5 the dependency representation to include design enti- 
ties created by both the directed and non-directed 
operations; and 
wherein the software modeling system further includes 
means for representing at least two of the plurality of 
io design entities in the dependency representation with a 
same hierarchical operator. 

19. The software modeling system of claim 15, wherein 
the plurality of functions includes directed and non-directed 
operations; 

i 5 the creating means includes means for creating the depen- 
dency representation to include design entities created 
by both directed and non-directed operations; and 
wherein the software modeling system further includes 
means for graphically editing the dependency repre- 
20 sentation to create a modified dependency representa- 
tion. 

20. The software modeling system of claim 15, wherein 
the plurality of functions includes directed and non-directed 
operations; 

25 wherein the creating means includes means for creating 
the dependency representation to include design enti- 
ties created by both directed and non-directed opera- 
tions; and 

wherein the software modeling system further includes 
means for generating a standard programming lan- 
guage computer program from the dependency repre- 
sentation. 

21. The software modeling system of claim 15, further 
^ including: 

means for displaying the dependency representation; and 
means for generating a standard programming language 
computer program from the dependency representa- 
tion. 

2Z The software modeling system of claim 15, wherein 
the plurality of functions includes a first function that 
operates upon a first set of arguments formatted in a first 
format, and wherein the software modeling system further 
includes means for providing a first wrapper around the first 
function, the first wrapper being capable of receiving a 
second set of arguments formatted in a second format that is 
different from the first format, the first wrapper converting 
the second set of arguments into the first set of arguments 
when calling the first function. 

23. The software modeling system as recited in claim 15, 
further comprising: 

means for, when a modification is made to the model, 
using the dependency representation to reevaluate only 
those functions used to create the model that corre- 
spond to the design entities affected by the modification 
to the model. 

24. The software modeling system of claim 15, wherein 
the plurality of functions includes directed and non-directed 
operations; 

wherein the creating means includes means for creating 
the dependency representation to include design enti- 
ties created by both directed and non-directed 
operations, and wherein the software modeling system 
further includes: 
means for representing at least two of the plurality of 
design entities in the dependency representation with a 
same hierarchical operator; 
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means for graphically editing the dependency represen- 
tation to create a modified dependency representation; 
and 

means for generating a standard programming language 
computer program from the dependency representa- 
tion. 

25. The software modeling system of claim 24, wherein 
the plurality of functions includes a first function that 
operates upon a set of arguments formatted in a first format, 
and wherein the software modeling system farther includes 
means for providing a first wrapper around the first function, 
the first wrapper being capable of receiving a second set of 
arguments formatted in a second format that is different from 
the first format, the first wrapper converting the second set 
of arguments into the first set of arguments when calling the 
first function. 

26. The software modeling system of claim 15, further 
including means for displaying the dependency representa- 
tion. 
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27. The software modeling system of claim 26, wherein 
the means for displaying the dependency representation 
includes a visual programming environment 

28. The software modeling system of claim 26, further 
5 including: 

means for representing at least two of the plurality of 
design entities in the dependency representation with a 
same hierarchical operator. 
10 29. The software modeling system of claim 26, further 
including: 

means for graphically editing the dependency represen- 
tation to create a modified dependency representation. 
30. The software modeling system of claim 29, further 
15 including: 

means for generating a modified design from the modified 
dependency representation. 



12/10/2003, EAST Version: 1.4.1 



